RE: Temporary slot leak when creation fails in a subtransaction

Dear Bharath,

> Here is a reproducer for a temporary logical slot [2]. The slot is
> left with restart_lsn and catalog_xmin set and confirmed_flush_lsn not
> set. A slot in that state can still be used for decoding, and with no
> confirmed_flush_lsn that can lose data (see the test case in the
> attached patch). There is no start point, and since decoding from the
> slot is not slot creation, the snapshot builder can restore a
> serialized snapshot and become consistent in the middle of a
> transaction that began before restart_lsn. Without the fix, the
> healthy slot in the test returns the transaction with both inserts and
> the leftover slot returns it with only the second one.

Confirmed that the temp slot could retain even after applying the premise patch.

> A few ways to fix this were discussed in the other thread.

FYI, I considered an alternative: register to resource owner. My idea was to
register the replication slot while creating the slot, and release or drop it based
on the needs, but it seems just introducing complexity. Also releasing callback
must not perform operations could fail like memory allocation, so it's not appropriate.

Best regards,
Hayato Kuroda
FUJITSU LIMITED