Question: pg_class attributes and race conditions ?

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Question: pg_class attributes and race conditions ?
Дата
Msg-id 45FA846D.5010603@enterprisedb.com
обсуждение исходный текст
Ответы Re: Question: pg_class attributes and race conditions ?  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Question: pg_class attributes and race conditions ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

What is the safest way to access/modify the pg_class attribute
and still avoid any race conditions with the other backends ?

A specific example is: To solve the CREATE INDEX problem with
HOT, I am thinking of adding (along with other things) a pg_class
boolean attribute, say hot_update_enable. All backends are
supposed to check this attribute before they perform an UPDATE.
The attribute would usually be available in relation->rd_rel

My understanding is that the backend which sets this attribute
must first acquire a lock on the heap relation of sufficient
strength so as to ensure that there are no concurrent UPDATErs,
update the pg_class row and then release the lock on the relation.
This would ensure that no backend has a stale "Relation"
pointer with stale value of hot_update_enable.

Also, should I use heap_inplace_update() rather than
simple_heap_update() because I want other backends to see the
change immediately irrespective of their snapshot ?

Is this a fair analysis ? Are there any rules I must follow
to avoid any deadlock and race conditions. I know we should
not be requesting a higher grade lock while holding a
lower grade lock, but are there any other restrictions/best
practices ?

Thanks,
Pavan

-- 


EnterpriseDB        http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mario Weilguni
Дата:
Сообщение: Re: Bug in UTF8-Validation Code?
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: Bug in UTF8-Validation Code?