Re: Buffer locking is special (hints, checksums, AIO writes)

Andres Freund <andres(at)anarazel(dot)de> 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