| 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: | Whole Thread | Raw Message | 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 |