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