On Sun, 31 Jan 2021 at 03:50, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Possibly you'd benefit from updating to v13, which has the listen/notify
> performance improvements Martijn referred to in the other thread.
>
> It's also possible that the hangup is unrelated to that, being somewhere
> later in commit processing than where the notify traffic gets dumped out.
> If you could identify which process has the "database 0" lock during one
> of these delays, and capture a stack trace from it, that would be
> super-informative.  Not sure about a good way to do that though.
> Maybe you could automate tailing the log for "DETAIL: Process holding the
> lock: nnn." and gdb'ing that process.
>
>                         regards, tom lane

Thanks for the reply Tom. We're running on Google Cloud SQL so we
won't be able to use gdb - unless we can convince Google to run it for
us :)

I wonder if there are any likely candidates that we could look into -
for example, is it possible it could be due a batched index update
that we could alleviate with "fastupdate=off"?

Cheers
Ben


Reply via email to