On Mon, Oct 26, 2026 at 8:55 PM Zhijie Hou <[email protected]> wrote: > > Hi, > > On Mon, Oct 26, 2026 at 12:59 PM shveta malik <[email protected]> wrote: > > > > On Mon, Oct 26, 2026 at 9:52 AM Amit Kapila <[email protected]> wrote: > > > > > > On Mon, Oct 26, 2026 at 9:08 AM shveta malik <[email protected]> > > > wrote: > > > > > > > > On Sat, Oct 24, 2026 at 11:42 AM Amit Kapila <[email protected]> > > > > wrote: > > > > > > > > > > The current use of the "datestyle" and other GUCs in libpqwalreceiver > > > > > or in other places is to keep the format portable across nodes but > > > > > here the CLT output will be usually human-readable. So, the same > > > > > analogy doesn't follow here. I am not convinced that this required > > > > > mid-way changing the GUCs temporarily. I feel we can document this > > > > > column and if we still get a request from field for portability of > > > > > this field(s) then we can consider using GUCs to make the format > > > > > consistent. > > > > > > > > > > > > > But it causes ambiguous results as shown in [1]. I am not sure how > > > > documentation will help here. As I see it, the stored key must > > > > convert back to the original value, not to some other value, > > > > especially since the patch’s own docs recommend casting it back to the > > > > column type before comparing. And I don’t think libpqwalreceiver does > > > > this for portability: its comment says it forces these GUCs so values > > > > are output “in a form that is unambiguous to the subscriber.” IMO, > > > > that’s the same goal here: avoiding a wrong stored value, not > > > > portability. > > > > > > > > > > That is a cross-node compatibility case and similarly pg_dump's output > > > could be restored on another node. I feel if a user changes the > > > datestyle or similar settings in-between different conflict-insertions > > > the results can change accordingly. We shouldn't take such guarantees. > > > It should be documented somewhere along with the following text [1], > > > we can probably give a small example as well. > > > > > > [1] > > > + <para> > > > + The apply worker's <xref linkend="guc-bytea-output"/> and > > > + <xref linkend="guc-quote-all-identifiers"/> settings change how a > > > value > > > + is written without changing the value itself. If these settings > > > differ > > > + between conflicts, the same key can be recorded in different but > > > + equivalent forms, and comparing the recorded text may miss some of > > > them. > > > > Okay. Let's do this, we can decide further if we have any real > > customer's feedback. > > Here is the updated patch set based on the discussion. The GUC-related logic > has been removed and doc is added. I've also improved a few comments about the > oversized column value and the reason for referring to the table's column name > rather than the index's. > > Only 0003 is changed. >
The doc and comment changes in 003 looks good (as per our discussion). + <xref linkend="guc-intervalstyle"/> affect how values are written and + interpreted. When casting such recorded values, use the same settings + that the apply worker used when recording the conflict; otherwise, the + original value may not be restored correctly. The little bit of concern I have is that there’s no way for the user to find out what settings the apply worker used when a particular conflict was inserted in the past. Even if they try to read it from the server log, they can’t match it to the CLT row, because we don’t record a conflict-insert timestamp, so there’s nothing to correlate against the log timeline. But okay as discussed, lets wait for user's feedback (if any) before changing it further. thanks Shveta
