From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Pavan Deolasee <pavan(dot)deolasee(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Question: pg_class attributes and race conditions ? |
Date: | 2007-03-16 14:52:21 |
Message-ID: | 20070316145221.GD3825@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-16 14:54:45 | Re: Lock table in non-volatile functions |
Previous Message | Teodor Sigaev | 2007-03-16 14:45:39 | Re: tsearch_core for inclusion |