Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Feb 12, 2020 at 11:53 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> * I see no reason to think that a relation extension lock would ever
>> be held long enough for noninterruptibility to be a real issue. Our
>> expectations for query cancel response time are in the tens to
>> hundreds of msec anyway.
> I don't agree, because (1) the time to perform a relation extension on
> a busy system can be far longer than that and (2) if the disk is
> failing, then it can be *really* long, or indefinite.
I remain unconvinced ... wouldn't both of those claims apply to any disk
I/O request? Are we going to try to ensure that no I/O ever happens
while holding an LWLock, and if so how? (Again, CheckpointLock is a
counterexample, which has been that way for decades without reported
problems. But actually I think buffer I/O locks are an even more
direct counterexample.)
>> * There are other places where an LWLock can be held for a *long* time,
>> notably the CheckpointLock. If we do think this is an issue, we could
>> devise a way to not insist on noninterruptibility. The easiest fix
>> is just to do a matching RESUME_INTERRUPTS after getting the lock and
>> HOLD_INTERRUPTS again before releasing it; though maybe it'd be worth
>> offering some slightly cleaner way. Point here is that LWLockAcquire
>> only does that because it's useful to the majority of callers, not
>> because it's graven in stone that it must be like that.
> That's an interesting idea, but it doesn't make the lock acquisition
> itself interruptible, which seems pretty important to me in this case.
Good point: if you think the contained operation might run too long to
suit you, then you don't want other backends to be stuck behind it for
the same amount of time.
> I wonder if we could have an LWLockAcquireInterruptibly() or some such
> that allows the lock acquisition itself to be interruptible. I think
> that would require some rejiggering but it might be doable.
Yeah, I had the impression from a brief look at LWLockAcquire that
it was itself depending on not throwing errors partway through.
But with careful and perhaps-a-shade-slower coding, we could probably
make a version that didn't require that.
regards, tom lane
