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 1st4f3-00DLTB-6g for pgsql-general@arkaria.postgresql.org; Tue, 24 Sep 2024 12:28:57 +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 1st4f2-007Kuu-6A for pgsql-general@arkaria.postgresql.org; Tue, 24 Sep 2024 12:28:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1st4f1-007KpH-Qm for pgsql-general@lists.postgresql.org; Tue, 24 Sep 2024 12:28:55 +0000 Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1st4ey-000q4h-Db for pgsql-general@lists.postgresql.org; Tue, 24 Sep 2024 12:28:55 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-277f0540c3aso2803721fac.3 for ; Tue, 24 Sep 2024 05:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727180931; x=1727785731; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=f/SekkoKr+78VnyhmVtyFkgxfRN2AXCbqM4QzDF9r0c=; b=E6KkDzrgTAzy1fDcPgjKarXTTLEQweFF08899Lx6DxQOT/5vGlUZx7xMJgwoQUNO7B d6I4kDBT80lOmPr9Pdhl6WEZBF1pLJmV63eKxvtUxn63AZbweR9qUV6/n/Z8Ot/a5cNz AauOo3SQnSuVyQfmR9w4BVH3sosh6w7LrRletKCAu8cCUOStelEoEQJ3iO8T/rkvAk0G hhe0uQEa4seWRzjhVI1f+W0RPg07mxEh65jUthFCNaCXaIkMtWuAq2LQck9KEKS3cHJQ iXJJG25g2fmJx2dCxKZtCWEu0PV9/U94NBwqn6/dvTO6hCFeSACmz7QvjlrXybM7VEux qGEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727180931; x=1727785731; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=f/SekkoKr+78VnyhmVtyFkgxfRN2AXCbqM4QzDF9r0c=; b=FsMvyuo/bCYKOlv43pgCz4xhnb6UHDQptmYYWHcEG7bkAqxIa+N2EG4kaMTW8bYAru Hp1/d7Jw8LFnfNtQrDw3zRQvSbbk5234+TRuw3yXFTR6nscMim93K7fRUfpoLTjdlhEY WWfw0K+4vaDtSPjzgHXRGLom4mUeZksTfd7HxuVeOu9xygvbDBbY6Bk+q0TumHxXWmTx z923kfMVUcSzZxrf3li4F7hg2TBU33mSqeeFvaWFyuZERl8hBTKshlTXPQc3gnStSdDs 0b0rx39L523xZRiuXR9S38/DA89xH9Z5g/NYxL9Ozll6ooaA8RiN+URzN4PxKmS56pTi ni2g== X-Gm-Message-State: AOJu0Yye8RtYrgXz0BKJ4dD3UKuxishGGhzD7xFeSl6WOqa7uRzc2DbQ 7tQmZOeEwuObQFMlTmtcTNouQuyM6FSUEPCjst2GzHGaeEObHURXI7QQ50o5mFTycMRHhvz9gJo U1qGca5UiohEyRS6KshooW0wxtdcr3w== X-Google-Smtp-Source: AGHT+IE/pFXEtSzf5+ZrPeuGIBV0socHn8LB3KH+Wh07lwkDB2w6HUiGETq3pkYKc8R4909S7UvnR25i14qgEGjJu7E= X-Received: by 2002:a05:6870:1616:b0:261:1600:b1eb with SMTP id 586e51a60fabf-2803d1152ecmr9225157fac.31.1727180931628; Tue, 24 Sep 2024 05:28:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7f47:0:b0:557:c384:fb61 with HTTP; Tue, 24 Sep 2024 05:28:51 -0700 (PDT) In-Reply-To: <9CEBFAC7-4372-4FF0-8124-FFFE834B03C6@gmail.com> References: <9CEBFAC7-4372-4FF0-8124-FFFE834B03C6@gmail.com> From: "David G. Johnston" Date: Tue, 24 Sep 2024 05:28:51 -0700 Message-ID: Subject: Re: Repeatable Read Isolation Level "transaction start time" To: Wizard Brony Cc: "pgsql-general@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000e485e20622dca58e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e485e20622dca58e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, September 23, 2024, Wizard Brony wrote: > https://www.postgresql.org/docs/16/transaction-iso.html# > XACT-REPEATABLE-READ > > The PostgreSQL documentation for the Repeatable Read Isolation Level > states the following: > > =E2=80=9CUPDATE, DELETE, MERGE, SELECT FOR UPDATE, and SELECT FOR SHARE c= ommands > behave the same as SELECT in terms of searching for target rows: they wil= l > only find target rows that were committed as of the transaction start tim= e.=E2=80=9D > > What is defined as the "transaction start time?" When I first read the > statement, I interpreted it as the start of the transaction: > > BEGIN; > SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; > > But in my testing, I find that according to that statement, the > transaction start time is actually "the start of the first > non-transaction-control statement in the transaction" (as mentioned earli= er > in the section). Is my conclusion correct, or am I misunderstanding the > documentation? > > Probably, since indeed the transaction cannot start at begin because once it does start it cannot be modified. David J. --000000000000e485e20622dca58e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, September 23, 2024, Wizard Brony <wizardbrony@gmail.com> wrote:
https://www.postgresql.org/d= ocs/16/transaction-iso.html#XACT-REPEATABLE-READ

The PostgreSQL documentation for the Repeatable Read Isolation Level states= the following:

=E2=80=9CUPDATE, DELETE, MERGE, SELECT FOR UPDATE, and SELECT FOR SHARE com= mands behave the same as SELECT in terms of searching for target rows: they= will only find target rows that were committed as of the transaction start= time.=E2=80=9D

What is defined as the "transaction start time?" When I first rea= d the statement, I interpreted it as the start of the transaction:

BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

But in my testing, I find that according to that statement, the transaction= start time is actually "the start of the first non-transaction-contro= l statement in the transaction" (as mentioned earlier in the section).= Is my conclusion correct, or am I misunderstanding the documentation?


Probably, since indeed the transaction can= not start at begin because once it does start it cannot be modified.
<= div>
David J.
=C2=A0
--000000000000e485e20622dca58e--