Christophe Pettus <xof@xxxxxxxxxxxx> writes: >> On Oct 9, 2017, at 13:26, Tom Lane <tgl@xxxxxxxxxxxxx> 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're clustered together. Could a large number of temporary table creations that are being undone by an abort cause this? Hmm. Creating or dropping a temp table does take AccessExclusiveLock, just as it does for a non-temp table. In principle we'd not have to transmit those locks to standbys, but I doubt that the WAL code has enough knowledge to filter them out. So a lot of temp tables and a lot of separate subtransactions could be a nasty combination. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
