BUG #17254: Crash with 0xC0000409 in pg_stat_statements when pg_stat_tmp\pgss_query_texts.stat exceeded 2GB. - Mailing list pgsql-bugs
From | PG Bug reporting form |
---|---|
Subject | BUG #17254: Crash with 0xC0000409 in pg_stat_statements when pg_stat_tmp\pgss_query_texts.stat exceeded 2GB. |
Date | |
Msg-id | 17254-a926c89dc03375c2@postgresql.org Whole thread Raw |
Responses |
Re: BUG #17254: Crash with 0xC0000409 in pg_stat_statements when pg_stat_tmp\pgss_query_texts.stat exceeded 2GB.
|
List | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 17254 Logged by: yusuke egashira Email address: egashira.yusuke@fujitsu.com PostgreSQL version: 14.0 Operating system: Windows Server 2019 Description: The database server was crashed with 0xC0000409 in pg_stat_statements. 2021-10-28 14:15:14.244 JST [4980] LOG: server process (PID 2556) was terminated by exception 0xC0000409 2021-10-28 14:15:14.244 JST [4980] DETAIL: Failed process was running: select count(1) from pg_stat_statements; 2021-10-28 14:15:14.244 JST [4980] HINT: See C include file "ntstatus.h" for a description of the hexadecimal value. This crash happened with PostgreSQL 14.0 for Windows downloaded from https://www.enterprisedb.com/download-postgresql-binaries. According to our investigation, when the pg_stat_statements reads the pg_stat_tmp\pgss_query_texts.stat, the server seems to crash with 0xC0000409 if the size of pgss_query_texts.stat exceeds about 2GB. Our user was performing tasks that executed a lot of very long SQL statements (INSERT statement with over 100,000 parameters), and the server crashed whenever pgss_query_texts.stat grew to a size larger than 2GB. Strangely, I had created the crashdumps directory under PGHOME, but a minidump file was not output. # Doesn't a crash with 0xC0000409 output a dump? I retrieved a minidump from postgres.exe which was rebuilt with enabled dumping by WindowsErrorReport. It seems that an exception occurred due to an argument error of _read(). * CHANGED: diff --git a/src/backend/main/main.c b/src/backend/main/main.c index e58e24a646..319c6ab62e 100644 --- a/src/backend/main/main.c +++ b/src/backend/main/main.c @@ -64,9 +64,6 @@ main(int argc, char *argv[]) * If supported on the current platform, set up a handler to be called if * the backend/postmaster crashes with a fatal signal or exception. */ -#if defined(WIN32) && defined(HAVE_MINIDUMP_TYPE) - pgwin32_install_crashdump_handler(); -#endif progname = get_progname(argv[0]); @@ -247,8 +244,6 @@ startup_hacks(const char *progname) exit(1); } - /* In case of general protection fault, don't show GUI popup box */ - SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX); * STACK_TEXT: ucrtbase!invoke_watson+0x18 ucrtbase!invalid_parameter+0x81 ucrtbase!invalid_parameter_noinfo+0x9 ucrtbase!_read+0x3aedc pg_stat_statements!qtext_load_file+0x112 pg_stat_statements!pg_stat_statements_internal+0x3ae pg_stat_statements!pg_stat_statements_1_9+0x17 postgres!ExecMakeTableFunctionResult+0x205 postgres!FunctionNext+0x62 postgres!ExecScanFetch+0x101 postgres!fetch_input_tuple+0x91 postgres!agg_retrieve_direct+0x245 postgres!ExecAgg+0x156 postgres!standard_ExecutorRun+0x13a pg_stat_statements!pgss_ExecutorRun+0xa1 postgres!PortalRunSelect+0x96 postgres!PortalRun+0x1ef postgres!exec_simple_query+0x627 postgres!PostgresMain+0x6e9 postgres!BackendRun+0x44 postgres!SubPostmasterMain+0x254 postgres!main+0x43b postgres!__scrt_common_main_seh+0x10c kernel32!BaseThreadInitThunk+0x14 ntdll!RtlUserThreadStart+0x21 The MSDN documentation says that the upper limit of the _read() argument is INT_MAX (about 2GB), but the size gotten by fstat() exceeds this limit, so I think we encountered server crash by an exception error. https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/read?view=msvc-160 > If buffer is NULL, or if buffer_size > INT_MAX, the invalid parameter handler is invoked. Until PostgreSQL 13, fstat() failed and returned ERROR when a file was larger than 2GB, but as a result of improvements to fstat() in PostgreSQL 14, it appears that _read() has exceeded its limit and now causes a crash.
pgsql-bugs by date: