Re: tuple concurrently updated - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tuple concurrently updated
Date
Msg-id 11307.1027873956@sss.pgh.pa.us
Whole thread Raw
In response to Re: tuple concurrently updated  (Curt Sampson <cjs@cynic.net>)
Responses Re: tuple concurrently updated  (Curt Sampson <cjs@cynic.net>)
List pgsql-hackers
Curt Sampson <cjs@cynic.net> writes:
> On Thu, 25 Jul 2002, Tom Lane wrote:
>> "Kangmo, Kim" <ilvsusie@hanafos.com> writes:
> If the index on the same class,
> two concurrent CREATE INDEX command can update pg_class.relpages
> at the same time.
>> 
>> Or try to, anyway.  The problem here is that the code that updates
>> system catalogs is not prepared to cope with concurrent updates
>> to the same tuple.

> I see. So the error is basically harmless, and can be rectified anyway
> with an ANALYZE, right?

Other than the fact that the second CREATE INDEX fails and rolls back,
there's no problem ;-)

I was thinking that it might help to have UpdateStats not try to update
the pg_class tuple if the correct value is already present.  This will
just narrow the window for failure, not eliminate it; but it'd be a
simple change and would probably help some.  Another thing to look at
is merging that routine with setRelhasindex so that a CREATE INDEX
involves only one update to the table's pg_class row, not two.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCHES] prepareable statements
Next
From: Curt Sampson
Date:
Subject: Re: tuple concurrently updated