On Mon, Oct 9, 2017 at 6:12 PM, Christophe Pettus <xof@thebuild.com> wrote:
>
>> On Oct 9, 2017, at 14:29, Tom Lane <tgl@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
singletransaction. It's made worse by one of those transactions finally getting replayed on the secondary, only to
haveanother 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