Re: relcache refcount

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: relcache refcount
Date: 2004-05-15 18:08:39
Message-ID: 7958.1084644519@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> Regarding the lock mechanism, I simply added some code to LockReleaseAll
> so it gets the array of committed child Xids; on subtransaction abort,
> the whole lock struct is scanned just like it's done on main transaction
> abort; only those locks affiliated with one of the given Xids are
> released. This is naive, so if it's incorrect please comment.

Another and perhaps simpler way would be to leave the release code
alone, but on subtransaction commit scan through the lock structs
and re-mark locks held by the subtrans as being held by the parent.
I think these are isomorphic functionally. The second way feels like
it would be faster (no inner loop over child XIDs). On the other hand,
if your current code does not require scanning the lock structures at
all on subtrans commit, it's probably not a win to add such a scan.

The lock algorithms must be able to tell when two lock requests are
coming from the same backend. At present I think this relies on
comparing XIDs, which is not going to work if you label subtrans locks
with subtrans XIDs. How are you thinking about handling that?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-05-15 18:27:44 Re: CatCache state reversing
Previous Message Tom Lane 2004-05-15 17:52:25 Re: Bogus permissions display in 7.4