| 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: | Whole Thread | Raw Message | 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 |