Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1no0lt-000695-T6 for pgsql-docs@arkaria.postgresql.org; Mon, 09 May 2022 10:37:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1no0ls-0003ph-PJ for pgsql-docs@arkaria.postgresql.org; Mon, 09 May 2022 10:37:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nnsKI-0005R8-2w for pgsql-docs@lists.postgresql.org; Mon, 09 May 2022 01:36:42 +0000 Received: from mail-yw1-x1130.google.com ([2607:f8b0:4864:20::1130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nnsKE-0006Mo-Ev for pgsql-docs@lists.postgresql.org; Mon, 09 May 2022 01:36:41 +0000 Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-2f7bb893309so128866967b3.12 for ; Sun, 08 May 2022 18:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TJ2BU4ExpKfmCZ1PkA1QX+1MpehZjvlwIuB5nN0ThMo=; b=kp+3uYpE3cnmRlL/fCbutjO5rAGHKRxMeyutrHgAsS4QwC1hRkPgRoRYLDjgr30G7L xyLuAiJynhHR32YGUfWJ5mEk37VCi3MWDPuk2k/eYGRvfL/8AQLlH9M0X4s/RzFvYp4f eBkpL80QeQi2ZE65Zmb0i6p0+yNxkYgINEU4n4gXjJvGADof3gcKhSeABjbZwuaN3bgp 2673icwttzd1lCZVr7mR+HoZWXNtcB2wTExG/JXYjCXU0hCuNyge0TDt8/PJ0KI3GIVc FHpQYjJo3no8q10w5T/S8HnAi02/d8zgaPVlSoFIJtSXOhLBd47oH4DotemBQH4Ak7VC B+gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TJ2BU4ExpKfmCZ1PkA1QX+1MpehZjvlwIuB5nN0ThMo=; b=HaC+cSwfLqt8S1W7PMbAbqaCykNUpy5nO0s5xQQdnbBW66O/eQnc2EvQfaiD6X76ij gqOuZnL8xH+qS58PEL9kPllfcsrg7YhVPpmHucxFp3vhd8tcz0HU2rTcxIQsS5EoqTyA qzxXMTHiLkKoUyjTuLmrw/kbAEmFDT8p8+6zYDM2vOZ0yHe3OxHu+i6NiqlAnHfWFFdD QIyD5b/MofnErrFb7su73ipx4faT6UcFzIy9nfVKE81pF6Q4IMQRdFaXnzpbvG7uiCGj A3M3K/vdAzhuNVD8eWgHoihwyqv/3MXJr/GhFYJUrNUvzMApEiwiH2DyoDD60wsBlPvC c60Q== X-Gm-Message-State: AOAM531cpE2k0U+1vTEZIifc3bzB3IdKKi/6gWK3q5QrndhGHqqInAc3 lj5ideqTe771YIoXK51NKg+YSQPYSRqVrKt41BnUJa7z X-Google-Smtp-Source: ABdhPJxxAVFzy6alm4hlyx0TqXK1RrS4I5eUswKMus4yzHVx8uTetMwRzMYDzT1U2QT86GjBXsPUPFFytHAjw0QDNV0= X-Received: by 2002:a81:cd6:0:b0:2f8:98ce:f053 with SMTP id 205-20020a810cd6000000b002f898cef053mr11859170ywm.327.1652060196700; Sun, 08 May 2022 18:36:36 -0700 (PDT) MIME-Version: 1.0 References: <165196152696.668.3099435890630131836@wrigleys.postgresql.org> In-Reply-To: From: Ivan Tsyba Date: Mon, 9 May 2022 04:36:24 +0300 Message-ID: Subject: Re: Docs about INSERT wait in Read Commited transaction To: "David G. Johnston" Cc: pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000002c09f205de8a3d7a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002c09f205de8a3d7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, the behavior is documented there. I would suggest to add one sentence about it to transactions page. Thank you =D0=BF=D0=BD, 9 =D1=82=D1=80=D0=B0=D0=B2. 2022, 04:27 =D0=BA=D0=BE=D1=80=D0= =B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1=87 David G. Johnston < david.g.johnston@gmail.com> =D0=BF=D0=B8=D1=88=D0=B5: > On Saturday, May 7, 2022, PG Doc comments form > wrote: > >> The following documentation comment has been logged on the website: >> >> Page: https://www.postgresql.org/docs/14/transaction-iso.html >> Description: >> >> Hello >> I've noticed, if two transactions in read committed mode are trying to >> insert same value to unique column, second transaction INSERT will wait >> for >> the first transaction commit or rollback. Can't see this behavior >> explicitly >> stated in the doc about transaction isolation modes. >> >> > It is documented elsewhere: > > https://www.postgresql.org/docs/current/index-unique-checks.html > > David J. > > --0000000000002c09f205de8a3d7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, the behavior is documented there. I would sugge= st to add one sentence about it to transactions page.

=
Thank you


<= div dir=3D"ltr" class=3D"gmail_attr">=D0=BF=D0=BD, 9 =D1=82=D1=80=D0=B0=D0= =B2. 2022, 04:27 =D0=BA=D0=BE=D1=80=D0=B8=D1=81=D1=82=D1=83=D0=B2=D0=B0=D1= =87 David G. Johnston <dav= id.g.johnston@gmail.com> =D0=BF=D0=B8=D1=88=D0=B5:
On Saturday, May 7, 2022, PG Doc comments form <<= a href=3D"mailto:noreply@postgresql.org" target=3D"_blank" rel=3D"noreferre= r">noreply@postgresql.org> wrote:
= The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/14/tran= saction-iso.html
Description:

Hello
I've noticed, if two transactions in read committed mode are trying to<= br> insert same value to unique column, second transaction INSERT will wait for=
the first transaction commit or rollback. Can't see this behavior expli= citly
stated in the doc about transaction isolation modes.


It is documented elsewhere:

=

David = J.
=C2=A0
--0000000000002c09f205de8a3d7a--