> On Oct 9, 2017, at 13:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> My bet is that the source server did something that's provoking O(N^2)
> behavior in the standby server's lock management. It's hard to say
> exactly what, but I'm wondering about something like a plpgsql function
> taking an AccessExclusiveLock inside a loop that repeatedly traps an
> exception. Can you correlate where the standby is stuck with what
> was happening on the source?
Interestingly, the OIDs for the relations on which the locks on the secondary are held aren't present in pg_class, and
they'reclustered together. Could a large number of temporary table creations that are being undone by an abort cause
this?
--
-- Christophe Pettus xof@thebuild.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general