On Thu, Jul 16, 2026 at 11:14 AM Nisha Moond <[email protected]> wrote: > > A zero-row result indicates the INSERT wasn't decoded, so seems > get_rel_sync_entry() wasn't reached. Sorry for the ambiguous test > steps -- the slot creation order matters. > Please follow these steps to reproduce the issue on HEAD: > > Session1: > CREATE TABLE t1 (a int) PARTITION BY RANGE (a); > CREATE TABLE t1_part PARTITION OF t1 FOR VALUES FROM (1) TO (100); > CREATE PUBLICATION mypub FOR ALL TABLES; > SELECT pg_create_logical_replication_slot('myslot', 'pgoutput'); > > Session 2: > BEGIN; > SELECT * FROM t1; > -- leave open > > Session 3 (hangs): > ALTER TABLE t1 DETACH PARTITION t1_part CONCURRENTLY; > > Session 4, while 3 is blocked: > INSERT INTO t1_part VALUES (5); > SELECT * FROM pg_logical_slot_get_binary_changes('myslot', NULL, > NULL, 'proto_version', '1', 'publication_names', 'mypub'); >
Okay thanks. I am able to reproduce the crash on HEAD now. We can pursue this in separate thread. I am not immediately clear on the solution yet. I think this is introduced by: https://www.postgresql.org/message-id/E1lPX7q-0001lJ-NO%40gemulon.postgresql.org it seems 'get_partition_parent' is changed to accept an arguement 'even_if_detached' to control whether caller wants detached partition or should error-out but no such arguement in get_partition_ancestors(). We can discuss this in separate thread. thanks Shveta
