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