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 1stYkW-00HMj2-R4 for pgsql-general@arkaria.postgresql.org; Wed, 25 Sep 2024 20:36: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 1stYkW-00DuVT-1Y for pgsql-general@arkaria.postgresql.org; Wed, 25 Sep 2024 20:36:36 +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 1stYkV-00DuTd-IM for pgsql-general@lists.postgresql.org; Wed, 25 Sep 2024 20:36:35 +0000 Received: from mail-oa1-x2f.google.com ([2001:4860:4864:20::2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1stYkS-0012xQ-TX for pgsql-general@lists.postgresql.org; Wed, 25 Sep 2024 20:36:34 +0000 Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-283b883ac8fso189938fac.3 for ; Wed, 25 Sep 2024 13:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727296592; x=1727901392; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=xB60dRKprhM33Sa+pMdH8MTu8UHqFL4F4fl/GZI8rF0=; b=i/0maapSxslw5WqYlECYivALR6veOv9pKpLta0HbuP/cek02uMw86qTIq2mk+QnFDz YzhQ3le0h9lGJicZCrHrINgpSnAYo7t18y2O6axtw3xMo13aiVzofI9yJWQHErOJfxdc x2f7HDRekNTpunJSlTm6FEvHa0IQRTXaAT7kPyhr2BMprhFYOuuhmfvjOaI5RkdnJcQn HDrAzb1UPc1SAlsW60X91AdTaVlQMQk2b2smg3jXt9RExgLvJcLPDSth4wT61zdzPl7D 3P0pHM/CPLApOK9xQjaMpuybgtEIrMLBHGX9d9YEvdn3h9ALDc80wgYeTi0fR9KeV5Pm 5UJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727296592; x=1727901392; h=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=xB60dRKprhM33Sa+pMdH8MTu8UHqFL4F4fl/GZI8rF0=; b=vZKCfAPy7/W0YULfZS39C3ko2rrD30fHGjcDCqV7V55kqtf7bmrj92M2zj1aK9AUcf HUWaDRXZQcLxyON2quPL1RGJ8qYIjWgF1zrak9qKRs/U72ol6g2yuJwci0s7UQFNbzpl EcchL8kBmM10Kc8vyTwvNK+Zhl/oLq9fIgvCJE9Kf/UyNmx4sxGna3jfQ2A6YP61PZhL hT0dq9WjjqXRySC0UzQRGMGDYYr3Q4JWCYXqAmvTdr9iEytztsZcTJVB/S28CLYlO3P8 C76VREKkyKPAtaD9HoTbENhv0h5KYF5JqPoWaJYTqHR6f+eOPu4luUO2ioWnLIKHBlcf V3ng== X-Gm-Message-State: AOJu0Yx4j2RCmTHAfND5AWrHqrLCe9U80YU1xUDvCAtJ9KEGRtP/Mhmy AEJem+0isNUfzIfYvOEP6wNB/W/Yp3SEeKzbZ+juVe90i2ZiH6PzdL6ZO8kAOJGRjQqy1ox2CQd m2ZuUTp32fW4N/jqCYw0S/FGTy1rOUw== X-Google-Smtp-Source: AGHT+IGmbihAJmWZGIGQUzQYddIYgS0OUfSo5Pnrry4P743wOWo9RCqthfdo2RRixkjVql3Xwi2y3KQgXi/V3yq5Whg= X-Received: by 2002:a05:6870:9616:b0:279:43d1:94fc with SMTP id 586e51a60fabf-286e175b281mr3783739fac.44.1727296591928; Wed, 25 Sep 2024 13:36:31 -0700 (PDT) MIME-Version: 1.0 References: <9CEBFAC7-4372-4FF0-8124-FFFE834B03C6@gmail.com> <3346993.1727188126@sss.pgh.pa.us> <28109.1727286817@sss.pgh.pa.us> In-Reply-To: From: Ron Johnson Date: Wed, 25 Sep 2024 16:36:20 -0400 Message-ID: Subject: Re: Repeatable Read Isolation Level "transaction start time" To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000c8a7200622f79365" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c8a7200622f79365 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 25, 2024 at 4:23=E2=80=AFPM Greg Sabino Mullane wrote: > On Wed, Sep 25, 2024 at 1:53=E2=80=AFPM Tom Lane wrot= e: > >> Because we're not going to analyze the statement in the amount of depth >> needed to make that distinction before we crank up the >> transactional machinery. If it says SELECT, it gets a snapshot. >> > > Ok, thanks. So to the original poster's point, perhaps the path with the > least side effects / best Principle of Least Surprise (POLS) support is t= o > start the transaction, and immediately call a "SELECT 1;" or perhaps bett= er > still, a 'SELECT timeofday();' > Since transactions should be "as short as possible, without being too short", how much time is there between when you run "BEGIN;" and the first "work statement"? --=20 Death to , and butter sauce. Don't boil me, I'm still alive. crustacean! --000000000000c8a7200622f79365 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 25, 2024 at 4:23=E2=80=AFPM G= reg Sabino Mullane <htamfids@gmail= .com> wrote:
On Wed, = Sep 25, 2024 at 1:53=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Becaus= e we're not going to analyze the statement in the amount of depth neede= d to make that distinction before we crank up the
transactional machinery.=C2=A0 If it says SELECT, it gets a snapshot.

Ok, thanks. So to the original poster's = point, perhaps the path with the least side effects / best Principle of Lea= st Surprise (POLS) support is to start the transaction, and immediately cal= l a "SELECT 1;" or perhaps better still, a 'SELECT timeofday(= );'
=C2=A0
Since transacti= ons should be "as short as possible, without being too short", ho= w much time is there between when you run "BEGIN;" and the first = "work statement"?

--
=
Death to <Redacted>, and butter sauce.
Don't= boil me, I'm still alive.
<Redacted> crustacean!
--000000000000c8a7200622f79365--