G'day all,
A quick follow-up on this issue for interest's sake. The stalling we
were seeing turned out to be a Cloud SQL issue and not related to our
listen/notify usage.
Cloud SQL has an automatic storage increase process that resizes the
underlying disk as required to account for cluster growth
On Mon, 1 Feb 2021 at 10:33, Tom Lane wrote:
>
> One thing that just occurred to me is that you might find it
> interesting to keep tabs on what's in the $PGDATA/pg_notify
> directory. Do the performance burps correspond to transitory
> peaks in the amount of data there? Or (grasping at straws h
Ben Hoskings writes:
> 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"?
No. This is late enough in the commit code path that we really
don't want to be runni
On Sun, 31 Jan 2021 at 03:50, Tom Lane 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 t
Ben Hoskings writes:
> We have a postgres 11.9 instance serving 7-8k queries/sec. In general
> it's humming along with no issues (p50 patency of ~1ms; p95 ~30ms).
> Lately though, we've seen occasional locking that causes all commits
> to the main database to be briefly blocked and the APIs that i
G'day all,
We have a postgres 11.9 instance serving 7-8k queries/sec. In general
it's humming along with no issues (p50 patency of ~1ms; p95 ~30ms).
Lately though, we've seen occasional locking that causes all commits
to the main database to be briefly blocked and the APIs that it backs
to stall.
