Re: Occasional lengthy locking causing stalling on commit - Mailing list pgsql-general

From Tom Lane
Subject Re: Occasional lengthy locking causing stalling on commit
Date
Msg-id 3252500.1612136034@sss.pgh.pa.us
Whole thread Raw
In response to Re: Occasional lengthy locking causing stalling on commit  (Ben Hoskings <ben@hoskings.net>)
Responses Re: Occasional lengthy locking causing stalling on commit  (Ben Hoskings <ben@hoskings.net>)
List pgsql-general
Ben Hoskings <ben@hoskings.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



pgsql-general by date:

Previous
From: Ben Hoskings
Date:
Subject: Re: Occasional lengthy locking causing stalling on commit
Next
From: Ben Hoskings
Date:
Subject: Re: Occasional lengthy locking causing stalling on commit