Re: ERROR: invalid memory alloc request size 1073741824

From: Stefan Blanke <stefan(dot)blanke(at)framestore(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-13 14:29:57
Message-ID: 1b7edcf7-b662-6b6f-87be-8882841d8064@framestore.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> 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?

Thanks, I'll add a count there and come back with a number when we next
hit the "invalid memory alloc".

Stefan

On 11/03/2020 15:37, Tom Lane wrote:
> 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

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2020-03-13 15:09:31 Re: pg_upgrade 9.6 to 12 without 9.6 binaries
Previous Message Zwettler Markus (OIZ) 2020-03-13 13:48:49 AW: vacuum full doubled database size