On Thu, Jul 16, 2026 at 11:14 AM Nisha Moond <nisha.moond412@gmail.com> 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
