Re: Proposal: Conflict log history table for Logical Replication - Mailing list pgsql-hackers

On Mon, 5 Jan 2026 at 09:59, shveta malik <shveta.malik@gmail.com> wrote:
>
> On Fri, Jan 2, 2026 at 12:06 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Fri, Dec 26, 2025 at 8:58 PM vignesh C <vignesh21@gmail.com> wrote:
> > >
> > >
> > > Here is a rebased version of the remaining patches.
> > >
> >
> > Thank You Vignesh. Please find a few comments on 004:
> >
>
> Vignesh, please find a few comments on 005.
>
> 1)
> AlterSubscriptionConflictLogDestination()
>
> + if (want_table && !has_oldtable)
> + {
> + char relname[NAMEDATALEN];
> +
> + snprintf(relname, NAMEDATALEN, "conflict_log_table_%u", sub->oid);
> +
> + relid = get_relname_relid(relname, PG_CONFLICT_NAMESPACE);
> + if (OidIsValid(relid))
>
>
> We have added this new scenario wherein we check if CLT is present
> already and if so, just set it in subid.
>
> a) Where will this scenario be hit? Can we please add the comments?
> On trying pg_dump, I see that it does not dump CLT and thus above will
> not be hit in pg_dump at least.

This is done for upgrade scenarios to associate with the pre-existing
conflict log table. Included comments.

> b) Even if we have a valid scenario where we have a pre-existing CLT
> and sub is created later, how/where are we ensuring that subid in CLT
> name will match newly generated subid?

It was generating different subid, updated it to preserve the old
subscription id.

> 2)
> + if (IsConflictLogTable(relid))
> + ereport(ERROR,
> + errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> + errmsg("conflict log table \"%s.%s\" cannot be used",
> +    nspname, relname),
> + errdetail("The specified table is already registered for a different
> subscription."),
> + errhint("Specify a different conflict log table."));
>
> a) Since the user is not specifying the CLT name, errhint seems incorrect.
>
> b) Again, I am unable to understand when this error will be hit? Since
> CLT is internally created using subid of owning subscription, how CLT
> of a particular subid be connected to subscription of different subid
> to result in above error? Can you please add comments to explain the
> situation.

 Now these error scenarios are not possible. Removed these.

The v19 version patch attached at [1] has the changes for the same.
[1] - https://www.postgresql.org/message-id/CALDaNm2YOOdJ25X1sJ%2BDYz37K6Qi4g0ZNFHb_pQMF9UqancnEA%40mail.gmail.com

Regards,
Vignesh