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. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
