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 1stWA5-00H35S-Si for pgsql-general@arkaria.postgresql.org; Wed, 25 Sep 2024 17:50:50 +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 1stWA5-00BxzI-4H for pgsql-general@arkaria.postgresql.org; Wed, 25 Sep 2024 17:50:49 +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 1stWA4-00BxsG-M2 for pgsql-general@lists.postgresql.org; Wed, 25 Sep 2024 17:50:48 +0000 Received: from mail-oo1-xc30.google.com ([2607:f8b0:4864:20::c30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1stWA2-0011pH-27 for pgsql-general@lists.postgresql.org; Wed, 25 Sep 2024 17:50:47 +0000 Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-5e5b57127e6so83439eaf.2 for ; Wed, 25 Sep 2024 10:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727286645; x=1727891445; 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=7sFRG9ub4Sv1YF5HUG8sHflkQKBFzW4pN0aWYd2eeYQ=; b=dtW2JEH4q0dOcZkn4lhAPBHvm6kKl51fTyud4XlQHsGO/3FLwZ6bys2jeOgG6dW3EQ IflxqR4TofhpDjunxtMULhGMf2kCm96pM2aYMSKK/WjlDBRZSHVJtcZ2TOT8oZQEJa6S y393mK8bPftqftGbVI4nfZj7bKMffbFNbYYxdQEm20WyBtGP5oZ7m2cUZFYVaoqaccPg YlgBk1MV6vvdKp/9rACduTOgk8k68V7InAyirO3AZDEt1UoIW/DIyRcwKMHiPd07ltPf VrIhYX+bexfihpSygK53nCrDsa0e2X+2bU8qpHXm3bArh/JIyLxG994NFdlabIdkSZLD 067A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727286645; x=1727891445; 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=7sFRG9ub4Sv1YF5HUG8sHflkQKBFzW4pN0aWYd2eeYQ=; b=uLBEcE1xmhN5aPXm9Cgxwi8kpYohw/9+Cs8RVNlhfbuIE0xIbmQVQaLS/tZMRunX2n 2kC77H/sMwsBdiDkjrX5KBZ+pGvI0N2gv5QgslJij63Avbs8yi1XIPPANu5RG8j3n+O0 2WmVZf6Nr2a7lyVAPs2Bs2iYBUO//+BeRrM7cuFL7ft//VosRrk+LrqYIe8odnUyiLpF y1Xbq2I7SKpWiaBkzyuIVM3WPMEofJOFdVvbhPk7Bw+4O95lqnRNYtXIZnxTBJYLJnz4 ONGiR0u5jYMZMgJlWTRw/uVKKTwtdM45rg5tkCuTFkG0BOnSUm4p9Mdts88m+NwH2Yjp nUXg== X-Gm-Message-State: AOJu0YwTB0v+eV0gbKXXLxJCAG8Oh3e0ZmnVc1wnnRzIvXuJoX8rQkAB 00C9A1Zx1o4IWutXuKYb/3m3hhTAz3U9eYY1/ANBzDGlW4UHFY8HkcSzdDJP3P8RTZ/TYCDOVZr Y6HhqJZdN7QtKiVy6MXWtjK7So2Sg6w== X-Google-Smtp-Source: AGHT+IH87J9otZ9U1vCGo/vr3MvzNpezhcmpb7ye/oNU90j/jmq9jjoT+jA26MEsPhOrtgD9UTbq7X/SFVbDZWatxHY= X-Received: by 2002:a05:6820:619:b0:5e1:e87d:9e75 with SMTP id 006d021491bc7-5e5c6a421aamr2126459eaf.5.1727286644977; Wed, 25 Sep 2024 10:50:44 -0700 (PDT) MIME-Version: 1.0 References: <9CEBFAC7-4372-4FF0-8124-FFFE834B03C6@gmail.com> <3346993.1727188126@sss.pgh.pa.us> In-Reply-To: From: Ron Johnson Date: Wed, 25 Sep 2024 13:50:33 -0400 Message-ID: Subject: Re: Repeatable Read Isolation Level "transaction start time" To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000e63adb0622f54201" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e63adb0622f54201 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 25, 2024 at 1:45=E2=80=AFPM Adrian Klaver wrote: > > > On 9/25/24 10:22 AM, Greg Sabino Mullane wrote: > > On Tue, Sep 24, 2024 at 10:28=E2=80=AFAM Tom Lane > > wrote: > > > > It's even looser than that, really: it's the first statement that > > requires an MVCC snapshot. > > > > > > Hm....so why does "SELECT 1;" work as a transaction start marker then, > > as opposed to "SHOW work_mem;", which does not? Do we simply consider > > anything with a SELECT as needing a snapshot? > > > SELECT some_func(); > > Where some_func() does something that requires a snapshot. > > But why does "SELECT 1;" need a snapshot? Heck, why does "SELECT ;" need a snapshot? --=20 Death to , and butter sauce. Don't boil me, I'm still alive. crustacean! --000000000000e63adb0622f54201 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 25, 2024 at 1:45=E2=80=AFPM A= drian Klaver <adrian.klaver= @aklaver.com> wrote:


On 9/25/24 10:22 AM, Greg Sabino Mullane wrote:
> On Tue, Sep 24, 2024 at 10:28=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us
> <mailto:tgl@= sss.pgh.pa.us>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0It's even looser than that, really: it's th= e first statement that
>=C2=A0 =C2=A0 =C2=A0requires an MVCC snapshot.
>
>
> Hm....so why does "SELECT 1;" work as a transaction start ma= rker then,
> as opposed to "SHOW work_mem;", which does not? Do we simply= consider
> anything with a SELECT as needing a snapshot?


SELECT some_func();

Where some_func() does something that requires a snapshot.


But why does "SELECT 1;" need a snapshot?= =C2=A0 Heck, why does "SELECT <immutable>;" need a snapshot= ?=C2=A0

--=
Dea= th to <Redacted>, and butter sauce.
Don't boil me, I'm st= ill alive.
<Redacted> crustacean!
--000000000000e63adb0622f54201--