Hi,
On Sun, Mar 29, 2026 at 1:16 PM Srinath Reddy Sadipiralla
<srinath2133@gmail.com> wrote:
>
> Hello,
>
> Thanks for the v5 patch set, I have reviewed and did initial testing on
> v5 patch set, and it LGTM, except these
Thank you for reviewing and testing. I appreciate it.
> diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
> index 286f0f46341..c2ff7e464f0 100644
> --- a/src/backend/replication/slot.c
> +++ b/src/backend/replication/slot.c
> @@ -1849,7 +1849,7 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
> else
> {
> /* translator: %s is a GUC variable name */
> - appendStringInfo(&err_detail, _("The slot's xmin %u is %d transactions old,
whichexceeds the configured \"%s\" value of %d."),
> + appendStringInfo(&err_detail, _("The slot's catalog_xmin %u is %d
transactionsold, which exceeds the configured \"%s\" value of %d."),
> catalog_xmin, (int32) (recentXid -
catalog_xmin),"max_slot_xid_age", max_slot_xid_age);
> }
Fixed the typo.
> while testing the active slot XID age invalidation (SIGTERM path) , i
> observed that slot got invalidated , walsender was killed because of
> SIGTERM , then starts the infinite-retry-cycle problem where
> walreceiver starts walsender and walsender will try to use an invalidated
> slot and dies, will think more on this.
I would like to clarify that once a slot is invalidated due to any of
the reasons (ReplicationSlotInvalidationCause), it becomes unusable;
the sender will error out if the receiver tries to use it. This is
consistent with all existing slot invalidation mechanisms.
Please find the attached v6 patches fixing the typo for further review.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
