Re: Proposal: Conflict log history table for Logical Replication

On Tue, Apr 28, 2026 at 7:53 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > 2.
> > +typedef enum ConflictLogDest
> > +{
> > + /* Log conflicts to the server logs */
> > + CONFLICT_LOG_DEST_LOG   = 1 << 0,   /* 0x01 */
> > +
> > + /* Log conflicts to an internally managed conflict log table */
> > + CONFLICT_LOG_DEST_TABLE = 1 << 1,   /* 0x02 */
> > +
> > + /* Convenience bitmask for all supported destinations */
> > + CONFLICT_LOG_DEST_ALL   = (CONFLICT_LOG_DEST_LOG | CONFLICT_LOG_DEST_TABLE)
> > +} ConflictLogDest;
> > +
> > +/*
> > + * Array mapping for converting internal enum to string.
> > + */
> > +static const char *const ConflictLogDestNames[] = {
> > + [CONFLICT_LOG_DEST_LOG] = "log",
> > + [CONFLICT_LOG_DEST_TABLE] = "table",
> > + [CONFLICT_LOG_DEST_ALL] = "all"
> > +};
> >
> > Defining an array this way could be an Array size issue. Actually the
> > array has just three elements so the last element should be at
> > ConflictLogDestNames[2] but if we go by the above definition, it will
> > be ConflictLogDestNames[3]. Can we define by referring the following
> > existing way:

I was analyzing this because I remember we were initially using the
format you suggested and switched to the bit format to enable direct
bitwise operations elsewhere.  I think Peter suggested that [1], and
the argument was that the bitwise operation is easy if we represent
them as a bit. Also, since we would not have too many options, the
array size shouldn't be an issue.  But I understand your point: adding
more elements will cause the array size to grow very fast as this is
using sparse array.  Let's see what others think about this, and then
we can decide whether to change it back?

[1] https://www.postgresql.org/message-id/CAHut%2BPtavTffweLWWQEK7JuDtwLPKhdqLysYg1ipjcoiW80%2B4g%40mail.gmail.com

-- 
Regards,
Dilip Kumar
Google