Re: relcache refcount

On Sat, May 15, 2004 at 02:08:39PM -0400, Tom Lane wrote:
> 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).

The problem is that the Xid is part of the locktag (which is the hash
key) as far as I can tell, so relabeling means I have to delete the lock
from the hashtable and then insert it again with the new tag. I don't
think this is a good idea.

(I found this out the hard way: I was getting "proclock hashtable
corrupted" when finishing a subtransaction after relabeling the locks).

> 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.

Nope, it doesn't.

> 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?

Nope, it doesn't compare Xids. That code actually looks up locks
through the PGPROC struct (procHolders), so the "current Xid" does not
affect it. Deadlock detection works without changing the code at all.

It took me quite a while to figure this out, as this is pretty hairy
code ... the hairiest I've seen in Postgres. I was surprised to learn
the original Berkeley code came without deadlock detection.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I call it GNU/Linux. Except the GNU/ is silent." (Ben Reiter)