From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Ross <jross(at)openvistas(dot)net> |
Cc: | PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: NOTIFY queue is at 66% and climbing... |
Date: | 2021-10-13 23:50:57 |
Message-ID: | 712282.1634169057@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jeff Ross <jross(at)openvistas(dot)net> writes:
> On 10.15 I'm getting the following on a logically replicated server.
> 2021-10-13 18:49:39.792 EDT,,,213601,,6143c257.34261,64243,,2021-09-16
> 18:16:55 EDT,4/3914851,60709901,WARNING,01000,"NOTIFY queue is 66%
> full",,,,,,,,,""
> In the CSV logs above what part points to "the session that is
> preventing cleanup" so that I can kill it?
Normally there's a DETAIL entry citing the session's PID. Looking
at the code, the reason for the lack of any such entry must be that
there is no session whose current notify queue position exactly
matches the supposed global minimum position. This corresponds to
a known bug that was fixed in 10.16, so I'd suggest upgrading.
As a temporary workaround you could restart that server, but
likely the problem would recur after awhile.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Tobias | 2021-10-14 03:02:08 | RE: Duplicate key in UUID primary key index... |
Previous Message | Phil Endecott | 2021-10-13 23:12:34 | Re: Replication between different architectures |