From: | Ben Hoskings <ben(at)hoskings(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Occasional lengthy locking causing stalling on commit |
Date: | 2021-01-31 23:18:43 |
Message-ID: | CACTv1A+2zhtcGDgrS5N2E4ho04d7CrvrOZ9GdWC1st2M-TPTcw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, 31 Jan 2021 at 03:50, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-01-31 23:33:54 | Re: Occasional lengthy locking causing stalling on commit |
Previous Message | Steve Singer | 2021-01-31 21:17:56 | Re: Offlne Slony Installation |