Re: Occasional lengthy locking causing stalling on commit
От | Ben Hoskings |
---|---|
Тема | Re: Occasional lengthy locking causing stalling on commit |
Дата | |
Msg-id | CACTv1A+2zhtcGDgrS5N2E4ho04d7CrvrOZ9GdWC1st2M-TPTcw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Occasional lengthy locking causing stalling on commit (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Occasional lengthy locking causing stalling on commit
|
Список | pgsql-general |
On Sun, 31 Jan 2021 at 03:50, Tom Lane <tgl@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
В списке pgsql-general по дате отправления: