MIME-Version: 1.0
References: <6634e1b0b5b74e5c2e3b06201120a81e11d82a55.camel@cybertec.at>
 <3bnBUxwx2npXqvHL0trI11LOOvzQ7LI0GzWqbaj5SJnk7DTb1uzStGveKwj0JJmBW4ebzGIF3az7of4I4rQeaO_PRqDnnClCduPyjM6gPgM=@scottray.io>
 <CAOzEurTC+5xuH_X2EBWjW0Fs9iuTq3OMA=1FfT4xx1wYbCAR6g@mail.gmail.com>
 <20260602.165755.1084850050958933598.horikyota.ntt@gmail.com>
 <qOUvBIi7LC3GLKEjACMQAhPnYaE1m7Ta6XbMXN1gOVo3Mh6-Be6o_kQxQeCNXfo-Ywgc8k6myZrco4a41z-r7Dfqro4-nH73cB_tmSOczJk=@scottray.io>
 <CAOzEurTohto7mfbmGu0GCHgAF+6roKxZgartyYydWsDkg3HzTg@mail.gmail.com>
In-Reply-To: 
 <CAOzEurTohto7mfbmGu0GCHgAF+6roKxZgartyYydWsDkg3HzTg@mail.gmail.com>
From: wenhui qiu <qiuwenhuifx@gmail.com>
Date: Wed, 3 Jun 2026 10:32:07 +0800
Message-ID: 
 <CAGjGUAKokqBPhw+56gU-3o3SOJe3d4TqPceCrS4K9gdYsw3ZsQ@mail.gmail.com>
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples
To: Shinya Kato <shinya11.kato@gmail.com>
Cc: Scott Ray <scott@scottray.io>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>, laurenz.albe@cybertec.at,
	japinli@hotmail.com, samimseih@gmail.com, pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000095b7350653503cc9"
Archived-At: 
 <https://www.postgresql.org/message-id/CAGjGUAKokqBPhw%2B56gU-3o3SOJe3d4TqPceCrS4K9gdYsw3ZsQ%40mail.gmail.com>
Precedence: bulk

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

HI Shinya
> I agree that exposing xid horizon retention information via a
> SQL-visible interface is valuable. However, I believe reporting it
> in the VACUUM log is also important: a view only shows the current
> state, so once a blocker has gone away there is no way to determine,
> after the fact, what was holding the horizon back at the time a
> particular VACUUM ran. Logs are the only durable record we have for
> that kind of post-hoc analysis.
Agree +1,There's no denying that checking SQL is easier than checking logs.
Logs are also important though. In fact, I think we should apply this patch
first and implement the SQL later.

Thanks

On Wed, Jun 3, 2026 at 9:25=E2=80=AFAM Shinya Kato <shinya11.kato@gmail.com=
> wrote:

> On Wed, Jun 3, 2026 at 10:05=E2=80=AFAM Scott Ray <scott@scottray.io> wro=
te:
> > I've been working on a view like this.  It shows the horizon
> > contribution for each backend, prepared xact, replication slot, and
> > HSF walsender, broken down by class.  It also shows - for each
> > contributor - how the horizon would shift if that holder were
> > removed.
> >
> > Shinya said [1] that we could have a view in the future.  We could
> > have both the logging and the view call a single function that reads
> > the procArray and other sources to gather the horizon information.  I
> > think the logging and the view would complement each other.
> >
> > Should I start another thread?
>
> My mild preference would be to keep the discussion on this thread,
> since the shared function design is central to both the log and the
> view and may be easier to keep aligned in one place. That said, I'm
> not strongly attached to that, so please pick whichever feels more
> convenient.
>
>
> --
> Best regards,
> Shinya Kato
> NTT OSS Center
>

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

<div dir=3D"ltr">HI=C2=A0Shinya<div>&gt; I agree that exposing xid horizon =
retention information via a<br>&gt; SQL-visible interface is valuable. Howe=
ver, I believe reporting it<br>&gt; in the VACUUM log is also important: a =
view only shows the current<br>&gt; state, so once a blocker has gone away =
there is no way to determine,<br>&gt; after the fact, what was holding the =
horizon back at the time a<br>&gt; particular VACUUM ran. Logs are the only=
 durable record we have for<br>&gt; that kind of post-hoc analysis.<br>Agre=
e +1,There&#39;s no denying that checking SQL is easier than checking logs.=
 Logs are also important though. In fact, I think we should apply this patc=
h first and implement the SQL later.</div><div><br></div><div>Thanks</div><=
/div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" =
class=3D"gmail_attr">On Wed, Jun 3, 2026 at 9:25=E2=80=AFAM Shinya Kato &lt=
;<a href=3D"mailto:shinya11.kato@gmail.com">shinya11.kato@gmail.com</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, =
Jun 3, 2026 at 10:05=E2=80=AFAM Scott Ray &lt;<a href=3D"mailto:scott@scott=
ray.io" target=3D"_blank">scott@scottray.io</a>&gt; wrote:<br>
&gt; I&#39;ve been working on a view like this.=C2=A0 It shows the horizon<=
br>
&gt; contribution for each backend, prepared xact, replication slot, and<br=
>
&gt; HSF walsender, broken down by class.=C2=A0 It also shows - for each<br=
>
&gt; contributor - how the horizon would shift if that holder were<br>
&gt; removed.<br>
&gt;<br>
&gt; Shinya said [1] that we could have a view in the future.=C2=A0 We coul=
d<br>
&gt; have both the logging and the view call a single function that reads<b=
r>
&gt; the procArray and other sources to gather the horizon information.=C2=
=A0 I<br>
&gt; think the logging and the view would complement each other.<br>
&gt;<br>
&gt; Should I start another thread?<br>
<br>
My mild preference would be to keep the discussion on this thread,<br>
since the shared function design is central to both the log and the<br>
view and may be easier to keep aligned in one place. That said, I&#39;m<br>
not strongly attached to that, so please pick whichever feels more<br>
convenient.<br>
<br>
<br>
-- <br>
Best regards,<br>
Shinya Kato<br>
NTT OSS Center<br>
</blockquote></div>

--00000000000095b7350653503cc9--