Re: startup process stuck in recovery

On Mon, Oct 9, 2017 at 6:12 PM, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>
>> On Oct 9, 2017, at 14:29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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