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 ?
Re: Question: pg_class attributes and race conditions ? |
Список | 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 по дате отправления: