Re: ERROR: invalid memory alloc request size 1073741824

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stefan Blanke <stefan(dot)blanke(at)framestore(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Jan Wieck <jan(at)wi3ck(dot)info>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: ERROR: invalid memory alloc request size 1073741824
Date: 2020-03-11 15:37:59
Message-ID: 6704.1583941079@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Stefan Blanke <stefan(dot)blanke(at)framestore(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Simon Riggs 2020-03-11 15:45:06 Re: Force WAL cleanup on running instance
Previous Message Stefan Blanke 2020-03-11 15:26:09 Re: ERROR: invalid memory alloc request size 1073741824