Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19500: pgrepack logical decoding plugin can crash assert builds
 via SQL decoding API
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: n.kalinin@postgrespro.ru
Reply-To: n.kalinin@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Date: Thu, 28 May 2026 14:54:26 +0000
Message-ID: <19500-38a02529a69353a5@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19500-38a02529a69353a5%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19500
Logged by:          Nikita Kalinin
Email address:      n.kalinin@postgrespro.ru
PostgreSQL version: 18.4
Operating system:   Fedora 44
Description:       =20

Hi,
It appears that the pgrepack output plugin is accessible through the SQL
logical decoding API, even though the plugin code explicitly indicates that
this interface is not supported. Reading changes from such a slot can cause
a backend process crash in builds with asserts enabled.
The crash is reproducible on the current master branch. Since the web form
does not allow selecting master, I selected the latest available released
version instead.

Steps to reproduce:
CREATE TABLE rp(a int);
SELECT *
FROM pg_create_logical_replication_slot('s_repack', 'pgrepack');
INSERT INTO rp VALUES (1);
SELECT *
FROM pg_logical_slot_get_binary_changes('s_repack', NULL, NULL);

Server log:

2026-05-28 21:32:23.185 +07 [142878] STATEMENT:  SELECT *
          FROM pg_create_logical_replication_slot('s_repack', 'pgrepack');
TRAP: failed Assert("RelationGetRelid(relation) =3D=3D private->relid"), Fi=
le:
"pgrepack.c", Line: 100, PID: 142878
postgres: nkpit postgres [local] SELECT(ExceptionalCondition+0x57)
[0xa2d437]
/tmp/pg/lib/postgresql/pgrepack.so(+0xa99) [0x7f7dd9332a99]

Backtrace:
#0  __pthread_kill_implementation (threadid=3D<optimized out>,
signo=3Dsigno@entry=3D6,
    no_tid=3Dno_tid@entry=3D0) at pthread_kill.c:44
#1  0x00007f7dd807a8d3 in __pthread_kill_internal (threadid=3D<optimized ou=
t>,
signo=3D6)
    at pthread_kill.c:89
#2  0x00007f7dd801f48e in __GI_raise (sig=3Dsig@entry=3D6) at
../sysdeps/posix/raise.c:26
#3  0x00007f7dd80067b3 in __GI_abort () at abort.c:77
#4  0x0000000000a2d458 in ExceptionalCondition (
    conditionName=3DconditionName@entry=3D0x7f7dd93337c8
"RelationGetRelid(relation) =3D=3D private->relid",
fileName=3DfileName@entry=3D0x7f7dd93337f5 "pgrepack.c",
    lineNumber=3DlineNumber@entry=3D100) at assert.c:65
#5  0x00007f7dd9332a99 in repack_process_change (ctx=3D<optimized out>,
    txn=3D<optimized out>, relation=3D<optimized out>, change=3D<optimized =
out>)
    at pgrepack.c:100
#6  0x0000000000821223 in change_cb_wrapper (cache=3D<optimized out>,
    txn=3D<optimized out>, relation=3D<optimized out>, change=3D<optimized =
out>)
    at logical.c:1111
#7  0x000000000082d91b in ReorderBufferApplyChange (rb=3D<optimized out>,
    txn=3D<optimized out>, relation=3D0x7f7dd848f7e8, change=3D0x29f71f10,
streaming=3Dfalse)
    at reorderbuffer.c:2080
#8  ReorderBufferProcessTXN (rb=3D0x29f55f20, txn=3D0x29f49e30,
commit_lsn=3D25673024,
    snapshot_now=3D<optimized out>, command_id=3Dcommand_id@entry=3D0,
    streaming=3Dstreaming@entry=3Dfalse) at reorderbuffer.c:2387
#9  0x000000000082dca9 in ReorderBufferReplay (txn=3D<optimized out>,
    rb=3D<optimized out>, commit_lsn=3D<optimized out>, end_lsn=3D<optimize=
d out>,
    commit_time=3D<optimized out>, origin_id=3D<optimized out>, origin_lsn=
=3D0,
    xid=3D<optimized out>) at reorderbuffer.c:2872
#10 0x000000000082ea38 in ReorderBufferCommit (rb=3D<optimized out>,
    xid=3D<optimized out>, commit_lsn=3D<optimized out>, end_lsn=3D<optimiz=
ed
out>,
    commit_time=3D<optimized out>, origin_id=3D<optimized out>,
origin_lsn=3D<optimized out>)
    at reorderbuffer.c:2896
#11 0x000000000081d075 in DecodeCommit (ctx=3D0x29f3de70, buf=3D0x7ffe263bd=
7e0,
    parsed=3D0x7ffe263bd630, xid=3D695, two_phase=3Dfalse) at decode.c:755
#12 xact_decode (ctx=3D0x29f3de70, buf=3D0x7ffe263bd7e0) at decode.c:254
#13 0x000000000081cbaa in LogicalDecodingProcessRecord
(ctx=3Dctx@entry=3D0x29f3de70,
    record=3D<optimized out>) at decode.c:117
#14 0x0000000000823b71 in pg_logical_slot_get_changes_guts
(fcinfo=3D0x29f2d400,
    confirm=3Dconfirm@entry=3Dtrue, binary=3Dbinary@entry=3Dtrue) at
logicalfuncs.c:267
#15 0x0000000000823d13 in pg_logical_slot_get_binary_changes
(fcinfo=3D<optimized out>)
    at logicalfuncs.c:354
#16 0x00000000006b7cb5 in ExecMakeTableFunctionResult (setexpr=3D0x29f279c8,
    econtext=3D0x29f27818, argContext=3D<optimized out>,
expectedDesc=3D0x29f2f348,
    randomAccess=3Dfalse) at execSRF.c:235
#17 0x00000000006ccad7 in FunctionNext (node=3D0x29f27608) at
nodeFunctionscan.c:95
#18 0x00000000006ac21a in ExecProcNode (node=3D0x29f27608)
    at ../../../src/include/executor/executor.h:327
#19 ExecutePlan (queryDesc=3D0x29e40780, operation=3DCMD_SELECT,
sendTuples=3Dtrue,
    numberTuples=3D0, direction=3D<optimized out>, dest=3D0x29f29618) at
execMain.c:1736
#20 standard_ExecutorRun (queryDesc=3D0x29e40780, direction=3D<optimized ou=
t>,
count=3D0)
    at execMain.c:377
#21 0x00000000008c5f98 in PortalRunSelect (portal=3Dportal@entry=3D0x29eb71=
30,
    forward=3Dforward@entry=3Dtrue, count=3D0, count@entry=3D92233720368547=
75807,
    dest=3Ddest@entry=3D0x29f29618) at pquery.c:917
#22 0x00000000008c767e in PortalRun (portal=3Dportal@entry=3D0x29eb7130,
    count=3Dcount@entry=3D9223372036854775807, isTopLevel=3DisTopLevel@entr=
y=3Dtrue,
    dest=3Ddest@entry=3D0x29f29618, altdest=3Daltdest@entry=3D0x29f29618,
    qc=3Dqc@entry=3D0x7ffe263bdd50) at pquery.c:761
#23 0x00000000008c3308 in exec_simple_query (
    query_string=3D0x29e13800 "SELECT *\n  FROM
pg_logical_slot_get_binary_changes('s_repack', NULL, NULL);") at
postgres.c:1290
#24 0x00000000008c4de1 in PostgresMain (dbname=3D<optimized out>,
    username=3D<optimized out>) at postgres.c:4856
#25 0x00000000008beddd in BackendMain (startup_data=3D<optimized out>,
    startup_data_len=3D<optimized out>) at backend_startup.c:124
#26 0x00000000007fed6e in postmaster_child_launch (child_type=3D<optimized
out>,
    child_slot=3D1, startup_data=3Dstartup_data@entry=3D0x7ffe263be1a0,
    startup_data_len=3Dstartup_data_len@entry=3D24,
    client_sock=3Dclient_sock@entry=3D0x7ffe263be1c0) at launch_backend.c:2=
68
#27 0x0000000000802776 in BackendStartup (client_sock=3D0x7ffe263be1c0)
    at postmaster.c:3627
#28 ServerLoop () at postmaster.c:1728
#29 0x0000000000804239 in PostmasterMain (argc=3Dargc@entry=3D3,
    argv=3Dargv@entry=3D0x29dbcfe0) at postmaster.c:1415
#30 0x00000000004a1b48 in main (argc=3D3, argv=3D0x29dbcfe0) at main.c:231

postgres=3D# select version();
                                                   version
---------------------------------------------------------------------------=
----------------------------------
 PostgreSQL 19devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 16.1.1
20260515 (Red Hat 16.1.1-2), 64-bit
(1 row)

Is this considered normal behavior for the pgrepack plugin, i.e. essentially
a =E2=80=9Cdon=E2=80=99t do that=E2=80=9D situation?