Thread

  1. Re: Proposal: Conflict log history table for Logical Replication

    shveta malik <shveta.malik@gmail.com> — 2026-05-21T07:08:28Z

    A few comments on v36-007:
    
    1)
    
    AlterSubscriptionConflictLogDestination
    + want_table = (logdest == CONFLICT_LOG_DEST_TABLE ||
    +   logdest == CONFLICT_LOG_DEST_ALL);
    + has_oldtable = (old_dest == CONFLICT_LOG_DEST_TABLE ||
    + old_dest == CONFLICT_LOG_DEST_ALL);
    
    Shall we replace checks at both places with CONFLICTS_LOGGED_TO_TABLE?
    
    2)
    I think we can move 'AlterSubscriptionConflictLogDestination' into the
    configuration patch itself (if needed). It is not directly used
    anywhere in upgrade flow as such. IIUC, even if upgrade flow uses it,
    it will only be used through AlterSubscription.
    
    3)
    AlterSubscriptionConflictLogDestination:
    
    + if (want_table && !has_oldtable)
    + {
    + char relname[NAMEDATALEN];
    +
    + snprintf(relname, NAMEDATALEN, "pg_conflict_log_for_subid_%u", sub->oid);
    +
    + /*
    + * In upgrade scenarios, the conflict log table already exists. Update
    + * the catalog to record the association.
    + */
    + relid = get_relname_relid(relname, PG_CONFLICT_NAMESPACE);
    + if (!OidIsValid(relid))
    + relid = create_conflict_log_table(sub->oid, sub->name, sub->owner);
    
    So this function will now be used during upgrade where destination is
    TABLE/ALL as well as regular Alter-Subscription to change destination
    from LOG to TABLE/ALL. In upgrade case, we expect the relid (CLT) to
    be present already while in regular case, we don't expect any CLT to
    be present.
    
    The above code does not take care of maintaining the sanity checks. It
    should be able to distinguish the 2 cases and Assert/Error if the
    condition is opposed to what we expect.
    
    4)
    Also , I do not understand how can upgrade ever pass this check:
    
    + if (want_table && !has_oldtable)
    
    It is not obvious how the upgrade flow will pass this check because
    theoretically both the old and new setup should have the exact same
    configuration; i.e. if  'want_table'  is true, 'has_oldtable' will be
    true. We can add a comment to clarify the situation here.
    
    thanks
    Shveta