On Mon, Oct 9, 2017 at 6:12 PM, Christophe Pettus <x...@thebuild.com> wrote: > >> On Oct 9, 2017, at 14:29, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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. > > The problem indeed appear to be a very large number of subtransactions, each > one creating a temp table, inside a single transaction. It's made worse by > one of those transactions finally getting replayed on the secondary, only to > have another one come in right behind it...
FYI, this is pathological coding; it can cause other nastiness such as exhausting shared memory. Consider refactoring the code to using a permanent table (if access is concurrent, you can do tricks like using 'pid' in the key to subdivide the data). merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
