Re: [GENERAL] Concurrency problem building indexes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] Concurrency problem building indexes
Дата
Msg-id 22427.1145985845@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] Concurrency problem building indexes  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: FOR UPDATE lock problem ?
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Catalog Access (was: [GENERAL] Concurrency problem building indexes)