Re: BUG #17254: Crash with 0xC0000409 in pg_stat_statements when pg_stat_tmp\pgss_query_texts.stat exceeded 2GB.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
Cc: egashira(dot)yusuke(at)fujitsu(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17254: Crash with 0xC0000409 in pg_stat_statements when pg_stat_tmp\pgss_query_texts.stat exceeded 2GB.
Date: 2021-10-31 17:07:42
Message-ID: 975808.1635700062@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <juanjo(dot)santamaria(at)gmail(dot)com> writes:
>> On Sat, Oct 30, 2021 at 6:26 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I think instead, we need to turn the subsequent one-off read() call into a
>>> loop that reads no more than INT_MAX bytes at a time. It'd be possible
>>> to restrict that to Windows, but probably no harm in doing it the same
>>> way everywhere.

>> Seems reasonable to me, can such a change be back-patched?

> Don't see why not.

Here's a quick patch for that. I don't have any ability to check it
on Windows, but the logic is easy to verify by reducing the arbitrary
constant to something small. (I used 1GB, not INT_MAX, because I figured
we ought to read in multiples of a filesystem block if possible.)

regards, tom lane

Attachment Content-Type Size
avoid-windows-failure-on-huge-read.patch text/x-diff 2.3 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Borodin 2021-10-31 19:01:08 Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Previous Message Tom Lane 2021-10-31 14:38:35 Re: BUG #17259: RETURN QUERY no longer accepts an UPDATE RETURNING