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
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 |