Re: BUG #17254: Crash with 0xC0000409 in pg_stat_statements when pg_stat_tmp\pgss_query_texts.stat exceeded 2GB.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Cc: egashira.yusuke@fujitsu.com,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2021-10-30T16:26:43Z
Lists: pgsql-bugs
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <juanjo.santamaria@gmail.com> writes: > Now, with 100% more patch attached. 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 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. 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? regards, tom lane
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