On Thu, 31 Oct 2024, 17:33 Andrey M. Borodin, <x4...@yandex-team.ru> wrote:
> > > > On 31 Oct 2024, at 17:29, Thom Brown <t...@linux.com> wrote: > > > > On Thu, 31 Oct 2024 at 10:47, Andrey M. Borodin <x4...@yandex-team.ru> > wrote: > >> > >> > >> > >>> On 29 Oct 2024, at 21:45, Thom Brown <t...@linux.com> wrote: > >>> > >>> It clearly checks for interrupts, but when I saw this issue happen, it > >>> wasn't interruptible. > >> > >> Perhaps, that was different multixacts? > >> When I was observing this pathology on Standby, it was a stream of > different reads encountering different multis. > >> > >> Either way startup can cancel locking process on it's own. Or is it the > case that cancel was not enough, did you actually need termination, not > cancel? > > > > Termination didn't work on either of the processes. > > How did you force the process to actually terminate? > Did you observe repeated read of the same multixact? > Was offending process holding any locks while waiting? > Unfortunately I didn't gather much information when it was occuring, and prioritised getting rid of the process blocking replay. I just attached gdb to it, got a backtrace and then "print ProcessInterrupts()". Thom >
