Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uqPLn-005Ngd-Vj for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Aug 2025 05:02:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uqPKp-006DTG-5E for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Aug 2025 05:01:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uqPKo-006DT7-Qa for pgsql-hackers@lists.postgresql.org; Mon, 25 Aug 2025 05:01:35 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uqPKm-001bVU-0P for pgsql-hackers@postgresql.org; Mon, 25 Aug 2025 05:01:34 +0000 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-333f7ebc44dso38754011fa.0 for ; Sun, 24 Aug 2025 22:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756098089; x=1756702889; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KzSJ1pyq6ZIjRP3naIoPEzM6gBSS+DQJb2WC1MIquWc=; b=hsNjYRSsiKA4+2IcyKbZIru23wz3tOUAWoTqKqtqu8yiV9AoNTBtYNPVmUo97jhaaP iScsNwbIcd65jjNRXa5A9y8nzrYqIN4e6/FGemcfnIpZ8SnL6GUSjmA3iUTOnJukAemc KhOe7crqiTkr7zFgn+SIlluoXfeFGk6uY9ZTWNKCnoIpVbn1g0mR69d8HsGlKm6NJolS MErUvpOZE/7cDTp+1V2PkYtpskLkqIYec5lDegIFaGObrKodq4zd+/B8KJ/+uEKS0NUY swpoIkjUucxeRv68J1IVcEH4ZlRpZ67VYZOOpctdosDl8hGN8kvBsK0T/Q/FzNIXiWn3 1I+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756098089; x=1756702889; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KzSJ1pyq6ZIjRP3naIoPEzM6gBSS+DQJb2WC1MIquWc=; b=lhx2SrVB0wlv3o+/tFv+3B46ct+OTT+mPtjBU5FLbCspaqWJiwe9O7KBnoxWTvcRA6 W8NdjPRT8j4mxS8aip/3vInne/pGeRhd5C1rOGM1if/5GJq3ggwZ9Sr+edWjrN4DsgHI ZDXG7ZDSpWmcVgAka617DbQYVMgh1Pgzyqq5d5yF0D9xYxZBv53z0WJBmd7EXQh7edl1 DcW5rjl7OidsbJy8viW2WzXLliRuB3UCHGXrl9yxBVL14T+b604EVcqL6hblJfyDNNUu pmGJ2v9veA94KxM9W76BEiQdrGxVje+/WDBNQIw89KS0jvD6k2caNM63CroTSsYjqDwS nUeg== X-Forwarded-Encrypted: i=1; AJvYcCWCByoXim2CnCRbLgu/PKDbLjscGaS7UkiEBDLbgTC7SRjNZoRWUDY/EiLv/5zw18sHuUG0CGGSeulJQARx@postgresql.org X-Gm-Message-State: AOJu0YzDrTvjjWu+iprTnHuuTjBH1KZfoxozhF4IOqbqi4oTvr6tTpz+ np7Q/8dhVYF864UQyNrz4azmy5cB0zzfdOUclKJT4cJYK6r1uXCS12LiatdF+YykfAfN93tUy7J tLaUTegznybOCEj3lIrvNPQfIFXfgB0k= X-Gm-Gg: ASbGncujWxDINXHDCO7xGob1UJeOVqKudLVO+/JDs3WI6AOBjoJKQswlaL03mhx/0VH XrtDea/eSphcCkLDuuWz6dPPCt4hEnBy+WfbIO2t9780Gl0UlN+b7+2OB1TXNLfppq02n75xKAe XEpTzUMu59vbte+DfC7nOQvlnLWNLL3Z3W74YNkwcDx25XfuYOkWI0rHyISJHEHZomDJnqML19R 7ZJPxNGtg== X-Google-Smtp-Source: AGHT+IE9/Jpc7HGv1jwkxF8VwWonide5hbAx57/ow4xdeoouFyoi6W2R8aevOTbw/34Na53IaSS4BSChRgj07zmB4vo= X-Received: by 2002:a2e:ae10:0:b0:333:b9db:f994 with SMTP id 38308e7fff4ca-33650c93795mr27628761fa.6.1756098089014; Sun, 24 Aug 2025 22:01:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Mon, 25 Aug 2025 10:31:17 +0530 X-Gm-Features: Ac12FXyFduiHPYZvttblLtV6kQFlxBvirh8KYawQdyRAi_jaNCX-QgnugsW0Pr4 Message-ID: Subject: Re: [BUG?] check_exclusion_or_unique_constraint false negative To: Mihail Nikalayeu Cc: "Zhijie Hou (Fujitsu)" , Peter Geoghegan , "Hayato Kuroda (Fujitsu)" , PostgreSQL Hackers , Andres Freund Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Aug 22, 2025 at 9:12=E2=80=AFPM Mihail Nikalayeu wrote: > > > BTW, as the update (or DELETE+INSERT) happens at a later time than the > > publisher's update/delete, so once we have the last_write_win > > resolution strategy implemented, it is the subscriber operation that > > will win. So, the current behavior shouldn't cause any problem. > > For the last_write_win and UPDATE vs UPDATE case - yes, probably, but > only by luck. > Why only by luck? > However, there are many scenarios that cannot be implemented > correctly, for example: > * DELETE always wins > * UPDATE with a higher version (column value) wins > * first_write_win > * etc. > Then these may not lead to eventual consistency for such cases. So, not sure one should anyway rely on these. > Also, the cases from [0] are clearly wrong without any conflict > resolution. In particular, case 2 - there are no real conflicts at all > (since different sets of columns are involved), but an incorrect > result may still be produced. > I think this questions whether we consider the SnapshotDirty results correct or not. The case of logical replication giving wrong results [0] is the behavior from the beginning of logical replication. Now, I would like to know the opinion of others who were involved in the initial commit, so added Peter E. to see what he thinks of the same. If we don't get the opinion here (say people missed to read because of an unrelated title) then I suggest you start a separate email thread to discuss just that case and see what others think. [0]: https://www.postgresql.org/message-id/flat/CADzfLwWC49oanFSGPTf%3D6FJo= Tw-kAnpPZV8nVqAyR5KL68LrHQ%40mail.gmail.com#5f6b3be849f8d95c166decfae541df0= 9 --=20 With Regards, Amit Kapila.