Stefan Blanke <stefan.blanke@framestore.com> writes:
> We've upgraded to PostgreSQL 11.5 (postgresql.org rhel 6 rpm) and I have
> had another occurrence of this invalid alloc of 1GB. Apologies for never
> providing a query plan when discussing this two years ago; we decided to
> move to a newer PostgreSQL to see if the issue went away but took a
> while to complete the move.
> The invalid alloc still only occurs occasionally every few months on a
> query that we run every minute; so unfortunately we still don't have a
> contained reproducible test case.
Given the lack of stats, I wonder whether the issue could be related
to the plan sometimes being horribly bad, eg due to the temp table
being much larger than expected. (A possible mechanism would be
hash table bloat, perhaps, but that's getting way ahead of the
evidence.)
Could you adjust your process to log the actual temp table size
each time, ie "select count(*) from temp_table" in between the
two steps, and then note whether the failures are correlated
with unusual temp table sizes?
regards, tom lane