On Wed, Feb 12, 2020 at 11:53 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Yeah. I would say a couple more things: > > * 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. > * 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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company