Thread

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

    Dilip Kumar <dilipbalaut@gmail.com> — 2025-12-18T09:55:26Z

    On Thu, Dec 18, 2025 at 2:39 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
    >
    > On Tue, Dec 16, 2025 at 9:51 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
    > >
    > > On Mon, Dec 15, 2025 at 5:11 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
    >
    > >
    > > We could do this as a first step. See the proposal in email [1] where
    > > we have discussed having two options instead of one. The first option
    > > will be conflict_log_format and the values would be log and table. In
    > > this case, the table would be an internally generated one.
    > >
    > > [1] - https://www.postgresql.org/message-id/CAA4eK1KwqE2y%3D_k5Xc%3Def0S5JXG2x%3DoeWpDJ%2B%3D5k6Anzaw2gdw%40mail.gmail.com
    >
    > So I have put more thought on this and here is what I am proposing
    >
    > 1) Subscription Parameter: Son in first version the subscription
    > parameter will be named 'conflict_log_format' which will accept
    > 'log/table/both' default option would be log.
    > 2) If conflict_log_format = log is provided then we do not need to do
    > anything as this would work by default
    > 3) If conflict_log_format = table/both is provided then we will
    > generate a internal table name i.e. conflict_log_table_$subid$ and the
    > table will be created in the current schema
    > 4) in pg_subscription we will still keep 2 field a) namespace id of
    > the conflict log table b) the conflict log format = 'log/table'both'
    > 5) If option is table/both the name can be generated on the fly
    > whether we are creating the table or inserting conflict into the
    > table.
    >
    > Question:
    > 1) Shall we create a conflict log table in the current schema or we
    > should consider anything else, IMHO the current schema should be fine
    > and in the future when we add an option for conflict_log_table we will
    > support schema qualified names as well?
    > 2) In catalog I am storing the "conflict_log_format" option as a text
    > field, is there any better way so that we can store in fixed format
    > maybe enum value as an integer we can do e.g. from below enum we can
    > store the integer value in system catalog for "conflict_log_format"
    > field, not sure if we have done such think anywhere else?
    >
    > typedef enum ConflictLogFormat
    > {
    > CONFLICT_LOG_FORMAT_DEFAULT = 0,
    > CONFLICT_LOG_FORMAT_LOG,
    > CONFLICT_LOG_FORMAT_TABLE,
    > CONFLICT_LOG_FORMAT_BOTH
    > } ConflictLogFormat;
    
    While exploring other kinds of options I think we can make it a char
    something like relkind as shown below, any other opinion on the same?
    
    #define CONFLICT_LOG_FORMAT_LOG = 'l'
    #define CONFLICT_LOG_FORMAT_TABLE = 't'
    #define CONFLICT_LOG_FORMAT_BOTH = 'b'
    
    -- 
    Regards,
    Dilip Kumar
    Google