Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Apr 9, 2012 at 1:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Haven't looked at the code, but maybe it'd be better to not bump the
>> strong lock count in the first place until the final step of updating
>> the lock tables?
> Well, unfortunately, that would break the entire mechanism. The idea
> is that we bump the strong lock count first. That prevents anyone
> from taking any more fast-path locks on the target relation. Then, we
> go through and find any existing fast-path locks that have already
> been taken, and turn them into regular locks. Finally, we resolve the
> actual lock request and either grant the lock or block, depending on
> whether conflicts exist.
OK. (Is that explained somewhere in the comments? I confess I've not
paid any attention to this patch up to now.) I wonder though whether
you actually need a *count*. What if it were just a flag saying "do not
take any fast path locks on this object", and once set it didn't get
unset until there were no locks left at all on that object? In
particular, it's not clear from what you're saying here why it's okay
to let the value revert once you've changed some of the FP locks to
regular locks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
