From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | cyberdemn(at)gmail(dot)com |
Subject: | BUG #15734: Walsender process crashing when executing SHOW ALL; |
Date: | 2019-04-04 07:54:19 |
Message-ID: | 15734-2daa8761eeed8e20@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 15734
Logged by: Alexander Kukushkin
Email address: cyberdemn(at)gmail(dot)com
PostgreSQL version: 11.2
Operating system: Ubuntu 18.04.2 LTS
Description:
According to the documentation [1], replication protocol supports SHOW
command, which is similar to the SQL command SHOW [2], so I tried to execute
"SHOW ALL;" and walsender crashed with the following stack-trace:
Program received signal SIGSEGV, Segmentation fault.
MemoryContextAlloc (context=0x0, size=104) at
./build/../src/backend/utils/mmgr/mcxt.c:783
783 ./build/../src/backend/utils/mmgr/mcxt.c: No such file or
directory.
(gdb) bt
#0 MemoryContextAlloc (context=0x0, size=104) at
./build/../src/backend/utils/mmgr/mcxt.c:783
#1 0x0000558b292beb97 in CopySnapshot (snapshot=0x558b29715060
<CatalogSnapshotData>) at ./build/../src/backend/utils/time/snapmgr.c:674
#2 0x0000558b292bf855 in RegisterSnapshotOnOwner (snapshot=0x558b29715060
<CatalogSnapshotData>, owner=0x558b2ae178c8) at
./build/../src/backend/utils/time/snapmgr.c:884
#3 0x0000558b292bf896 in RegisterSnapshot (snapshot=<optimized out>) at
./build/../src/backend/utils/time/snapmgr.c:868
#4 0x0000558b28ece60f in systable_beginscan
(heapRelation=heapRelation(at)entry=0x7f96bedb2cc8, indexId=<optimized out>,
indexOK=<optimized out>, snapshot=snapshot(at)entry=0x0, nkeys=nkeys(at)entry=1,
key=key(at)entry=0x7ffe14269ec0)
at ./build/../src/backend/access/index/genam.c:356
#5 0x0000558b2926bfd3 in SearchCatCacheList (cache=0x558b2ae2f700,
nkeys=nkeys(at)entry=1, v1=16384, v2=v2(at)entry=0, v3=v3(at)entry=0) at
./build/../src/backend/utils/cache/catcache.c:1650
#6 0x0000558b2927e2ee in SearchSysCacheList (cacheId=cacheId(at)entry=8,
nkeys=nkeys(at)entry=1, key1=<optimized out>, key2=key2(at)entry=0,
key3=key3(at)entry=0) at ./build/../src/backend/utils/cache/syscache.c:1427
#7 0x0000558b2917ef50 in roles_is_member_of (roleid=roleid(at)entry=16384) at
./build/../src/backend/utils/adt/acl.c:4862
#8 0x0000558b29182717 in is_member_of_role (member=16384,
role=role(at)entry=3374) at ./build/../src/backend/utils/adt/acl.c:4946
#9 0x0000558b2929fe0a in ShowAllGUCConfig (dest=<optimized out>) at
./build/../src/backend/utils/misc/guc.c:8280
#10 GetPGVariable (name=<optimized out>, dest=<optimized out>) at
./build/../src/backend/utils/misc/guc.c:8184
#11 0x0000558b2911b7aa in exec_replication_command
(cmd_string=cmd_string(at)entry=0x558b2ade36b0 "SHOW ALL;") at
./build/../src/backend/replication/walsender.c:1555
#12 0x0000558b291696a6 in PostgresMain (argc=<optimized out>,
argv=argv(at)entry=0x558b2ae125d8, dbname=<optimized out>, username=<optimized
out>) at ./build/../src/backend/tcop/postgres.c:4178
#13 0x0000558b290f4a7d in BackendRun (port=0x558b2ae0c690) at
./build/../src/backend/postmaster/postmaster.c:4361
#14 BackendStartup (port=0x558b2ae0c690) at
./build/../src/backend/postmaster/postmaster.c:4033
#15 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1706
#16 0x0000558b290f5abf in PostmasterMain (argc=17, argv=0x558b2adde020) at
./build/../src/backend/postmaster/postmaster.c:1379
#17 0x0000558b28e824c2 in main (argc=17, argv=0x558b2adde020) at
./build/../src/backend/main/main.c:228
I don't think that such a crash is expected behavior. Either it should
return the table with all settings or report simply error out with message
'unrecognized configuration parameter "ALL"'.
[1] https://www.postgresql.org/docs/11/protocol-replication.html
[2] https://www.postgresql.org/docs/11/sql-show.html
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2019-04-04 10:31:09 | Re: BUG #15733: An insert destined at partition created after a column has been dropped from the parent table fails |
Previous Message | Jeremy Evans | 2019-04-04 06:16:13 | Re: BUG #15722: 9000x performance regression on query starting PostgreSQL 10 due to bad query plan |