On Fri, Feb 14, 2020 at 9:13 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Feb 12, 2020 at 11:53 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > 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. >
It is not clear to me why we should add that as a requirement for this patch when other places like WALWriteLock, etc. have similar coding patterns and we haven't heard a ton of complaints about making it interruptable or if there are then I am not aware. > > 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. > If this becomes a requirement to move this patch, then surely we can do that. BTW, what exactly we need to ensure for it? Is it something on the lines of ensuring that in error path the state of the lock is cleared? Are we worried that interrupt handler might do something which will change the state of lock we are acquiring? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
