Re: Question: pg_class attributes and race conditions ?

Pavan Deolasee wrote:
> 
> 
> 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.

FWIW this is pretty much the same I wanted to do with setting
relfrozenxid to FrozenTransactionId.  To this end I wrote a patch to add
a catalog pg_ntclass (later renamed to pg_class_nt), which was
ultimately rejected for reasons I don't remember at the time.  Maybe it
would be illuminating to investigate that -- please see the archives.

(I still think it would be good to have a pg_class_nt catalog, so it's
not a dead idea).

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.