MIME-Version: 1.0
References: <CANtu0oiktqQ2pwExoXqDpByXNCJa-KE5vQRodTRnmFHN_+qwHg@mail.gmail.com>
 <CANtu0ohU2XRV9shtu14CffLPDS1x10q7ebOGf-vX0p+45_L8jw@mail.gmail.com>
 <CANtu0oh0tspW-xWzDGWP9ehz96KPt9aUP1c9JYhdBYxKsB0jpA@mail.gmail.com>
 <CANtu0ohUB9ky45iiMAYN1fGyt82+cg=+UYBom=P7drb+=97G9w@mail.gmail.com>
 <TYAPR01MB56921C9C3D21B0D62FF76330F5B22@TYAPR01MB5692.jpnprd01.prod.outlook.com>
 <CANtu0og=5v4j8onS4nyJ4zMPdh-EPFxmiEi5PLoyZrmqHA6RKw@mail.gmail.com>
 <CAA4eK1Jfb0xviXYon-_TvHNKeAY7ngAeo++Knu-0RPR6EkSBjA@mail.gmail.com>
 <CANtu0ohHmYXsK5bxU9Thcq1FbELLAk0S2Zap0r8AnU3OTmcCOA@mail.gmail.com> <CAA4eK1+_V1PWXrrgAM01p+CByP6JwYRxejZrcxOu83a-v_+zZg@mail.gmail.com>
In-Reply-To: <CAA4eK1+_V1PWXrrgAM01p+CByP6JwYRxejZrcxOu83a-v_+zZg@mail.gmail.com>
From: Michail Nikolaev <michail.nikolaev@gmail.com>
Date: Mon, 5 Aug 2024 13:11:50 +0200
Message-ID: <CANtu0ogDDQnXbrv6p7Xtc2dT_MZ1fjdPgB9-0B5Lw1b4pQGd2A@mail.gmail.com>
Subject: Re: [BUG?] check_exclusion_or_unique_constraint false negative
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, 
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>
Content-Type: multipart/alternative; boundary="00000000000017980e061eedbf5d"
Archived-At: <https://www.postgresql.org/message-id/CANtu0ogDDQnXbrv6p7Xtc2dT_MZ1fjdPgB9-0B5Lw1b4pQGd2A%40mail.gmail.com>
Precedence: bulk

--00000000000017980e061eedbf5d
Content-Type: text/plain; charset="UTF-8"

Hello!

> Right, but we are extending this functionality to detect and resolve
> such conflicts [1][2]. I am hoping after that such updates won't be
> missed.

Yes, this is a nice feature. However, without the DirtySnapshot index scan
fix, it will fail in numerous instances, especially in master-master
replication.

The update_missing feature is helpful in this case, but it is still not the
correct event because a real tuple exists, and we should receive
update_differ instead. As a result, some conflict resolution systems may
malfunction. For example, if the resolution method is set to apply_or_skip,
it will insert the new row, causing two rows to exist. This system is quite
fragile, and I am sure there are many more complicated scenarios that could
arise.
Best regards,
Mikhail.

--00000000000017980e061eedbf5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello!<div><br></div><div>&gt; Right, but we are extending=
 this functionality to detect and resolve<br>&gt;=C2=A0such conflicts [1][2=
]. I am hoping after that such updates won&#39;t be<br>&gt;=C2=A0missed.<br=
></div><div><p>Yes, this is a nice feature. However, without the DirtySnaps=
hot index scan fix, it will fail in numerous instances, especially in maste=
r-master replication.</p><p>The update_missing feature is helpful in this c=
ase, but it is still not the correct event because a real tuple exists, and=
 we should receive update_differ instead. As a result, some conflict resolu=
tion systems may malfunction. For example, if the resolution method is set =
to apply_or_skip, it will insert the new row, causing two rows to exist. Th=
is system is quite fragile, and I am sure there are many more complicated s=
cenarios that could arise.</p></div><div><font color=3D"#000000" face=3D"sa=
ns-serif"><span style=3D"font-size:12.7px">Best regards,</span></font></div=
><div><font color=3D"#000000" face=3D"sans-serif"><span style=3D"font-size:=
12.7px">Mikhail.</span></font></div><div><br></div><div><br></div><div><br>=
</div></div>

--00000000000017980e061eedbf5d--