RE: Simplify code building the LR conflict messages - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Simplify code building the LR conflict messages
Date
Msg-id TY7PR01MB145543A31502A3507F5FCE439F588A@TY7PR01MB14554.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Simplify code building the LR conflict messages  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Simplify code building the LR conflict messages
List pgsql-hackers
Dear Shveta,

> 1)
> append_tuple_value_detail():
> +/*
> + * Helper function to build the additional details for conflicting key,
> + * existing local row, remote row, and replica identity columns.
> + */
> we can get rid of 'existing' from this comment too.
>
> Same is true for header-comment of obtain_tuple_values().

I removed all the term 'exsting local row', not only the function header.

> 3)
> errdetail_apply_conflict()
> 
> - *
> - * The DETAIL line comprises of two parts:
> - * 1. Explanation of the conflict type, including the origin and commit
> - *    timestamp of the existing local row.
> - * 2. Display of conflicting key, existing local row, remote new row, and
> - *    replica identity columns, if any. The remote old row is excluded as its
> - *
> 
> Why did we remove this part? IMO, it still makes sense.

I removed because INSERT_EXISTS/UPDATE_EXISTS/CT_UPDATE_DELETED has two lines,
and each ones have the explanation and display part.

But... after reading again, I noticed that "The DETAIL line comprises..." meant
that even if DETAIL has two lines, each one consists of parts. Thus I restored.

Here is an updated version. Comments from Shveta were addressed and a translator
note was added in append_tuple_value_detail(). Outputs were not updated.

Lastly, I was not included example for INSERT_EXISTS and UPDATE_EXISTS, because
I thought these cases were included in CT_MULTIPLE_UNIQUE_CONFLICTS. But let me
share them just in case. Here a long string was used as the value.

INSERT_EXISTS:
Head)
DETAIL:  Key already exists in unique index "huga_pkey", modified locally in transaction 800 at 2026-xxx.
Key (id)=(1); existing local row (1, testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...); remote row
(1,testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...).
 

Patched)
DETAIL:  Could not apply remote change: remote row (1,
testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...).
Key already exists in unique index "huga_pkey", modified locally in transaction 800 at 2026-xxx: key (id)=(1), local
row(1, testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...).
 

UPDATE_EXISTS:
Head)
DETAIL:  Key already exists in unique index "huga_pkey", modified locally in transaction 801 at 2026-xxx.
Key (id)=(2); existing local row (2, testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...); remote row
(2,testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...); replica identity (id)=(1).
 

Patched)
DETAIL:  Could not apply remote change: remote row (2,
testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...),replica identity (id)=(1).
 
Key already exists in unique index "huga_pkey", modified locally in transaction 801 at 2026-xxx: key (id)=(2), local
row(2, testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...).
 

Best regards,
Hayato Kuroda
FUJITSU LIMITED


Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: Dilip Kumar
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication