Server Crash in logical decoding if used inside --single mode - Mailing list pgsql-hackers

From tushar
Subject Server Crash in logical decoding if used inside --single mode
Date
Msg-id 6bc3e8c1-1170-5af3-8bbe-97dd0e804fe2@enterprisedb.com
Whole thread Raw
Responses Re: Server Crash in logical decoding if used inside --single mode
List pgsql-hackers
Hi,

Steps to reproduce on Master Sources -

.) Perform initdb ( ./initdb -D data)

.) set wal_level=logical in postgresql.conf file

.)Connect to psql in single-user mode  ( ./postgres --single  -D data  
postgres)

.)Create logical replication slot followed by select * from 
pg_logical_slot_get_changes

backend>  SELECT * FROM pg_create_logical_replication_slot('m7', 
'test_decoding','f');
      1: slot_name    (typeid = 19, len = 64, typmod = -1, byval = f)
      2: lsn    (typeid = 3220, len = 8, typmod = -1, byval = t)
     ----
2019-03-06 17:27:42.080 GMT [1132] LOG:  logical decoding found 
consistent point at 0/163B9C8
2019-03-06 17:27:42.080 GMT [1132] DETAIL:  There are no running 
transactions.
2019-03-06 17:27:42.080 GMT [1132] STATEMENT:   SELECT * FROM 
pg_create_logical_replication_slot('m7', 'test_decoding','f');

      1: slot_name = "m7"    (typeid = 19, len = 64, typmod = -1, byval = f)
      2: lsn = "0/163BA00"    (typeid = 3220, len = 8, typmod = -1, 
byval = t)
     ----
backend> select * from pg_logical_slot_get_changes('m7',null,null);
      1: lsn    (typeid = 3220, len = 8, typmod = -1, byval = t)
      2: xid    (typeid = 28, len = 4, typmod = -1, byval = t)
      3: data    (typeid = 25, len = -1, typmod = -1, byval = f)
     ----
2019-03-06 17:28:04.979 GMT [1132] LOG:  starting logical decoding for 
slot "m7"
2019-03-06 17:28:04.979 GMT [1132] DETAIL:  Streaming transactions 
committing after 0/163BA00, reading WAL from 0/163B9C8.
2019-03-06 17:28:04.979 GMT [1132] STATEMENT:  select * from 
pg_logical_slot_get_changes('m7',null,null);

2019-03-06 17:28:04.979 GMT [1132] LOG:  logical decoding found 
consistent point at 0/163B9C8
2019-03-06 17:28:04.979 GMT [1132] DETAIL:  There are no running 
transactions.
2019-03-06 17:28:04.979 GMT [1132] STATEMENT:  select * from 
pg_logical_slot_get_changes('m7',null,null);

TRAP: FailedAssertion("!(slot != ((void *)0) && slot->active_pid != 0)", 
File: "slot.c", Line: 428)
Aborted (core dumped)

Stack trace -

(gdb) bt
#0  0x0000003746e325e5 in raise () from /lib64/libc.so.6
#1  0x0000003746e33dc5 in abort () from /lib64/libc.so.6
#2  0x00000000008a96ad in ExceptionalCondition (conditionName=<value 
optimized out>, errorType=<value optimized out>, fileName=<value 
optimized out>, lineNumber=<value optimized out>)
     at assert.c:54
#3  0x0000000000753253 in ReplicationSlotRelease () at slot.c:428
#4  0x0000000000734dbd in pg_logical_slot_get_changes_guts 
(fcinfo=0x2771e48, confirm=true, binary=false) at logicalfuncs.c:355
#5  0x0000000000640aa5 in ExecMakeTableFunctionResult 
(setexpr=0x27704f8, econtext=0x27703a8, argContext=<value optimized 
out>, expectedDesc=0x2792c10, randomAccess=false)
     at execSRF.c:233
#6  0x0000000000650c43 in FunctionNext (node=0x2770290) at 
nodeFunctionscan.c:95
#7  0x000000000063fbad in ExecScanFetch (node=0x2770290, 
accessMtd=0x650950 <FunctionNext>, recheckMtd=0x6501d0 
<FunctionRecheck>) at execScan.c:93
#8  ExecScan (node=0x2770290, accessMtd=0x650950 <FunctionNext>, 
recheckMtd=0x6501d0 <FunctionRecheck>) at execScan.c:143
#9  0x00000000006390a7 in ExecProcNode (queryDesc=0x276fc28, 
direction=<value optimized out>, count=0, execute_once=144) at 
../../../src/include/executor/executor.h:241
#10 ExecutePlan (queryDesc=0x276fc28, direction=<value optimized out>, 
count=0, execute_once=144) at execMain.c:1643
#11 standard_ExecutorRun (queryDesc=0x276fc28, direction=<value 
optimized out>, count=0, execute_once=144) at execMain.c:362
#12 0x000000000079e30b in PortalRunSelect (portal=0x27156b8, 
forward=<value optimized out>, count=0, dest=<value optimized out>) at 
pquery.c:929
#13 0x000000000079f671 in PortalRun (portal=0x27156b8, 
count=9223372036854775807, isTopLevel=true, run_once=true, 
dest=0xa826a0, altdest=0xa826a0, completionTag=0x7ffc04af2690 "")
     at pquery.c:770
#14 0x000000000079ba7b in exec_simple_query (query_string=0x27236f8 
"select * from pg_logical_slot_get_changes('m7',null,null);\n") at 
postgres.c:1215
#15 0x000000000079d044 in PostgresMain (argc=<value optimized out>, 
argv=<value optimized out>, dbname=0x26c9010 "postgres", username=<value 
optimized out>) at postgres.c:4256
#16 0x00000000006874eb in main (argc=5, argv=0x26a7e20) at main.c:224
(gdb) q

-- 
regards,tushar
EnterpriseDB  https://www.enterprisedb.com/
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump is broken for partition tablespaces
Next
From: Robert Haas
Date:
Subject: Re: openLogOff is not needed anymore