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.
