Stefan Blanke <stefan.blanke@xxxxxxxxxxxxxx> 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
