BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and swithing cache->snapshot - Mailing list pgsql-bugs

From PG Bug reporting form
Subject BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and swithing cache->snapshot
Date
Msg-id 17804-2a118cd046f2d0e5@postgresql.org
Whole thread Raw
Responses Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and swithing cache->snapshot  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-bugs
The following bug has been logged on the website:

Bug reference:      17804
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 15.2
Operating system:   Ubuntu 22.04
Description:

The following transaction:
BEGIN;
SET LOCAL stats_fetch_consistency = cache;
SELECT * FROM pg_stat_database;
SET LOCAL stats_fetch_consistency = snapshot;
SELECT pg_stat_get_function_calls(0);

raises an assertion failure with the following stack:
Core was generated by `postgres: law regression [local] SELECT
                        '.
Program terminated with signal SIGABRT, Aborted.

warning: Section `.reg-xstate/1355782' in core file too small.
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140663482824512) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140663482824512) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140663482824512) at
./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140663482824512, signo=signo@entry=6) at
./nptl/pthread_kill.c:89
#3  0x00007feec4a1a476 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#4  0x00007feec4a007f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x0000555cf0603315 in ExceptionalCondition (
    conditionName=0x555cf07ecf38 "pgStatLocal.snapshot.stats->members == 0",

    errorType=0x555cf07ec974 "FailedAssertion", fileName=0x555cf07ecc8f
"pgstat.c", lineNumber=948)
    at assert.c:69
#6  0x0000555cf045e815 in pgstat_build_snapshot () at pgstat.c:948
#7  0x0000555cf045e39b in pgstat_fetch_entry (kind=PGSTAT_KIND_FUNCTION,
dboid=16384, objoid=0)
    at pgstat.c:798
#8  0x0000555cf0461fae in pgstat_fetch_stat_funcentry (func_id=0) at
pgstat_function.c:242
#9  0x0000555cf0544c66 in pg_stat_get_function_calls (fcinfo=0x555cf164cb68)
at pgstatfuncs.c:384
#10 0x0000555cf01b7396 in ExecInterpExpr (state=0x555cf164ca80,
econtext=0x555cf164c780, 
    isnull=0x7ffe50dc040f) at execExprInterp.c:751
#11 0x0000555cf01b964e in ExecInterpExprStillValid (state=0x555cf164ca80,
econtext=0x555cf164c780, 
    isNull=0x7ffe50dc040f) at execExprInterp.c:1826
#12 0x0000555cf0217315 in ExecEvalExprSwitchContext (state=0x555cf164ca80,
econtext=0x555cf164c780, 
    isNull=0x7ffe50dc040f) at ../../../src/include/executor/executor.h:341
#13 0x0000555cf021738d in ExecProject (projInfo=0x555cf164ca78)
    at ../../../src/include/executor/executor.h:375
#14 0x0000555cf02175d7 in ExecResult (pstate=0x555cf164c668) at
nodeResult.c:136
#15 0x0000555cf01d022d in ExecProcNodeFirst (node=0x555cf164c668) at
execProcnode.c:464
#16 0x0000555cf01c34ee in ExecProcNode (node=0x555cf164c668) at
../../../src/include/executor/executor.h:259
#17 0x0000555cf01c63f5 in ExecutePlan (estate=0x555cf164c430,
planstate=0x555cf164c668, 
    use_parallel_mode=false, operation=CMD_SELECT, sendTuples=true,
numberTuples=0, 
    direction=ForwardScanDirection, dest=0x555cf16519a0, execute_once=true)
at execMain.c:1636
#18 0x0000555cf01c3c25 in standard_ExecutorRun (queryDesc=0x555cf165bba0,
direction=ForwardScanDirection, 
    count=0, execute_once=true) at execMain.c:363
#19 0x0000555cf01c3a10 in ExecutorRun (queryDesc=0x555cf165bba0,
direction=ForwardScanDirection, count=0, 
    execute_once=true) at execMain.c:307
#20 0x0000555cf043cae6 in PortalRunSelect (portal=0x555cf15eeb90,
forward=true, count=0, dest=0x555cf16519a0)
    at pquery.c:924
#21 0x0000555cf043c704 in PortalRun (portal=0x555cf15eeb90,
count=9223372036854775807, isTopLevel=true, 
    run_once=true, dest=0x555cf16519a0, altdest=0x555cf16519a0,
qc=0x7ffe50dc0810) at pquery.c:768
#22 0x0000555cf0435590 in exec_simple_query (
    query_string=0x555cf1582570 "SELECT pg_stat_get_function_calls(0);") at
postgres.c:1250
#23 0x0000555cf043a4af in PostgresMain (dbname=0x555cf15aea18 "regression",
username=0x555cf15ae9f8 "law")
    at postgres.c:4593
#24 0x0000555cf035fd2b in BackendRun (port=0x555cf15a6130) at
postmaster.c:4511
#25 0x0000555cf035f5b2 in BackendStartup (port=0x555cf15a6130) at
postmaster.c:4239
#26 0x0000555cf035b53f in ServerLoop () at postmaster.c:1806
#27 0x0000555cf035ac9c in PostmasterMain (argc=3, argv=0x555cf157da30) at
postmaster.c:1478
#28 0x0000555cf024ebdd in main (argc=3, argv=0x555cf157da30) at main.c:202

It appeared with the stats_fetch_consistency introduction (5891c7a8e).

Looks like pgstat_fetch_entry() can fill up the snapshot.stats structure
and it's contents preserved when switching the consistency mode,
what pgstat_build_snapshot() doesn't expect.


pgsql-bugs by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: BUG #17789: process_pgfdw_appname() fails for autovacuum workers
Next
From: Andrey Lepikhov
Date:
Subject: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware)