On Fri, Dec 19, 2025 at 9:53 AM Dilip Kumar <[email protected]> wrote: > > On Fri, Dec 19, 2025 at 9:40 AM Amit Kapila <[email protected]> wrote: > > > > On Fri, Dec 19, 2025 at 4:38 AM Masahiko Sawada <[email protected]> > > wrote: > > > > > > On Thu, Dec 18, 2025 at 1:09 AM Dilip Kumar <[email protected]> wrote: > > > > > > > > > > > 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; > > > > > > How about making conflict_log_format accept a list of destinations > > > instead of having the 'both' option in case where we might add more > > > destination options in the future? > > > > > > It seems to me that conflict_log_destination sounds better. > > > > > > > Yeah, this is worth considering. But say, we need to extend it so that > > the conflict data goes in xml format file instead of standard log then > > won't it look a bit odd to specify via conflict_log_destination. I > > thought we could name it similar to the existing > > auto_explain.log_format. > > IMHO conflict_log_destination sounds more appropriate considering we > are talking about the log destination instead of format no? And the > option could be log/table/file etc, and for now we can just stick to > log/table. And in future we can extend it by supporting extra options > like destination_name, where we can provide table name or file name > etc. So let me list down all the points which need consensus. > > 1. What should be the name of the option 'conflict_log_destination' vs > 'conflict_log_format'
I prefer conflcit_log_destination. > 2. Do we want to support multi destination then providing string like > 'conflict_log_destination = 'log,table,..' make more sense but then we > would have to store as a string in catalog and parse it everytime we > insert conflicts or alter subscription OTOH currently I have just > support single option log/table/both which make things much easy > because then in catalog we can store as a single char field and don't > need any parsing. And since the input are taken as a string itself, > even if in future we want to support more options like 'log,table,..' > it would be backward compatible with old options. I feel, combination of options might be a good idea, similar to how 'log_destination' provides. But it can be done in future versions and the first draft can be a simple one. > 3. Do we want to support 'none' destinations? i.e. do not log to anywhere? IMO, conflict information is an important piece of information to diagnose data divergence and thus should be logged always. Let's wait for others' opinions. thanks Shveta
