Re: [GENERAL] Concurrency problem building indexes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Concurrency problem building indexes
Date
Msg-id 22427.1145985845@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Concurrency problem building indexes  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> I'm late to this thread, but maybe we can make the process of storing
> the new data in pg_class take a lock using LockObject() or something
> like that to serialize the access to the pg_class row.

I'm inclined to think that the right solution is to fix UpdateStats and
setRelhasindex so that they don't use simple_heap_update, but call
heap_update directly and cope with HeapTupleUpdated (by looping around
and trying the update from scratch).

Another thing that's annoying here is that we update the pg_class row
twice in some cases --- really we ought to try to get this down to one
update.  (So we'd only need one instance of the looping logic not two.)
I'm not entirely clear on the cleanest way to do that, but am currently
thinking that btbuild and friends ought to pass back the tuple counts
they obtained, rather than writing them into the catalogs for
themselves.  IndexCloseAndUpdateStats ought to go away --- the index AM
never had any business doing that for itself.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: FOR UPDATE lock problem ?
Next
From: "Jim C. Nasby"
Date:
Subject: Catalog Access (was: [GENERAL] Concurrency problem building indexes)