Re: Occasional lengthy locking causing stalling on commit

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ben Hoskings <ben(at)hoskings(dot)net>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Occasional lengthy locking causing stalling on commit
Date: 2021-01-31 23:33:54
Message-ID: 3252500.1612136034@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ben Hoskings <ben(at)hoskings(dot)net> 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 running anything that would take a long time or
have a significant probability of failure. So I'm a bit mystified
as to what it could be. Ockham's razor suggests that it's the
notify processing itself, as you seem to be an outlier in how
heavily you're using that; but that's no sure thing.

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 here...)
wraparound of the file names back to 0000?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ben Hoskings 2021-02-01 01:33:51 Re: Occasional lengthy locking causing stalling on commit
Previous Message Ben Hoskings 2021-01-31 23:18:43 Re: Occasional lengthy locking causing stalling on commit