Andres Freund <[email protected]> writes:
> Anyway, independent of that, the behavior clearly needs to be allowed. Here's
> a proposed patch.
> At first I was thinking of just removing the assertion without anything else
> in place - but I think that's not quite right: We could e.g. be trying to
> acquire a share or share-exclusive lock when holding a share lock (or the
> reverse), but we can't currently don't keep track of two different lock modes
> for the same lock. Therefore it seems safer to just define it so that
> acquiring a conditional lock on a buffer that is already locked by us will
> always fail, regardless of what existing lock mode we already hold. I think
> all current callers good with that.
> Does that sound reasonable?
I didn't read the patch, but I agree with this description of what the
behavior should be.
> We could add support for locking the same buffer multiple times, but I don't
> think it'd be worth the complexity and (small) overhead that would bring with
> it?
Also agreed --- I think that's behavior we actively don't want.
> It also seems like allowing that would make it more likely for a backend
> to trample over its own state higher up in the call tree.
Precisely.
regards, tom lane
