MIME-Version: 1.0
References: <CANzqJaBjwtzLg_bZHkokUJbtA8gy6RpHjirfdBH9OJGfn5=tmw@mail.gmail.com>
 <28109.1727286817@sss.pgh.pa.us> <CAKAnmmLDpwgqu071t_Q7Fq349dYAgQim1x46U1DCAiiTcUmU2A@mail.gmail.com>
 <CANzqJaAAQFD_JvK=ChmfdGCRNP0G5gMtVBgF52bZiFjQxH8N_Q@mail.gmail.com>
 <CAKAnmmL05Lt89EOnMW111qdUOau+dYG7u8ff5o+ckKKohnNwGg@mail.gmail.com>
 <DD2C10F3-2A3C-44AB-AAC5-10BB15B15498@thebuild.com> <20240925215554.gfg24h5sp5aqesxv@hjp.at>
 <152525.1727302184@sss.pgh.pa.us> <20241005091424.34il2ss4noazgegx@hjp.at>
 <368259fb-fd2e-4a05-89e9-a733fae6d964@aklaver.com> <20241005203327.nb52nfuopdsjilvd@hjp.at>
 <1166698.1728162188@sss.pgh.pa.us>
In-Reply-To: <1166698.1728162188@sss.pgh.pa.us>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Mon, 7 Oct 2024 11:12:21 -0400
Message-ID: <CAKAnmm+iqt48mC7_PWk--7i1WB49_bX0HsjLSLs7x9k2LmmiSw@mail.gmail.com>
Subject: Re: Repeatable Read Isolation Level "transaction start time"
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Peter J. Holzer" <hjp-pgsql@hjp.at>, pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000b462680623e47499"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmm%2Biqt48mC7_PWk--7i1WB49_bX0HsjLSLs7x9k2LmmiSw%40mail.gmail.com>
Precedence: bulk

--000000000000b462680623e47499
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 5, 2024 at 5:03=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> As I mentioned upthread, we currently promise that xact_start matches the
> query_start of the transaction's first statement.  (I'm not sure
> how well that's documented, but the code goes out of its way to make it
> so, so somebody thought it was important.)
>

I'm not convinced this is terribly useful in practice, but it is good to
know.

I think if we wanted to do something here, it'd make more sense to keep
> xact_start as it stands and introduce a new variable
> snapshot_timestamp or something like that.


I agree; I've been thinking about something like this, as it is too hard to
try to shoehorn the information into the existing fields. Will throw this
onto my "possible patch idea" pile.

Then maybe we could have some guarantees about what you get when comparing
> other sessions'
> xact_start to your own snapshot_timestamp.  But I'm not convinced we can
> really guarantee anything without reading the snapshot_timestamp within t=
he
> snapshot-collecting critical section, and I'm not for that.
>

Fair enough, but even a not-guaranteed 100% accurate value might be better
than the current situation, which is no (user) visibility at all about the
(MVCC) visibility. Heck, even a boolean "snapshot acquired" would be an
improvement (which becomes a subset of the info returned by a timestamp via
null/notnull).

Cheers,
Greg

--000000000000b462680623e47499
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Oct 5, 2024 at 5:03=E2=80=AFPM To=
m Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; w=
rote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">As I mentioned upthread, we currently promise that xact_st=
art matches the query_start of the transaction&#39;s first statement.=C2=A0=
 (I&#39;m not sure<br>
how well that&#39;s documented, but the code goes out of its way to make it=
 so, so somebody thought it was important.)<br></blockquote><div><br></div>=
<div>I&#39;m not convinced this is terribly useful in practice, but it is g=
ood to know.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">I think if we wanted to do something here, it&#39;d make more sense=
 to keep xact_start as it stands and introduce a new variable<br>
snapshot_timestamp or something like that.</blockquote><div><br></div><div>=
I agree; I&#39;ve been thinking about something like this, as it is too har=
d to try to shoehorn the information into the existing fields. Will throw t=
his onto my &quot;possible patch idea&quot; pile.</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Then maybe we could have some =
guarantees about what you get when comparing other sessions&#39;<br>
xact_start to your own snapshot_timestamp.=C2=A0 But I&#39;m not convinced =
we can really guarantee anything without reading the snapshot_timestamp wit=
hin the snapshot-collecting critical section, and I&#39;m not for that.<br>=
</blockquote><div><br></div><div>Fair enough, but even a not-guaranteed 100=
% accurate value might be better than the current situation, which is no (u=
ser) visibility at all about the (MVCC) visibility. Heck, even a boolean &q=
uot;snapshot acquired&quot; would be an improvement (which becomes a subset=
 of the info returned by a timestamp via null/notnull).</div><div><br></div=
><div>Cheers,</div><div>Greg</div><div><br></div><div><br></div></div></div=
>

--000000000000b462680623e47499--