Re: BUG #17254: Crash with 0xC0000409 in pg_stat_statements when pg_stat_tmp\pgss_query_texts.stat exceeded 2GB.
Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
From: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: egashira.yusuke@fujitsu.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2021-10-30T18:31:05Z
Lists: pgsql-bugs
On Sat, Oct 30, 2021 at 6:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > That seems like a pretty poor solution. It will cause pg_stat_statements > to fail altogether as soon as the stats file exceeds 1GB. (Admittedly, > failing is better than crashing, but not by that much.) Worse, it causes > that to happen on EVERY platform, not only Windows where the problem is. > > I don't think it is a Windows only problem, even on POSIX platforms it might not be safe trying to read() over 2GB. > 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? > A different line of thought is that maybe we shouldn't be letting the > file get so big in the first place. Letting every backend have its > own copy of a multi-gigabyte stats file is going to be problematic, > and not only on Windows. It looks like the existing logic just considers > the number of hash table entries, not their size ... should we rearrange > things to keep a running count of the space used? > > +1. There should be a mechanism to limit the effective memory size. Regards, Juan José Santamaría Flecha
Commits
-
Don't try to read a multi-GB pg_stat_statements file in one call.
- fdb60ca83d03 9.6.24 landed
- d87d5f8d8d3a 10.19 landed
- a667b0668378 15.0 landed
- 7104e0b2457d 14.1 landed
- 5dd067430b9d 11.14 landed
- 3a5b313ce748 13.5 landed
- 16d0da5c8dda 12.9 landed