Feedback-ID: i0c21471d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1108-g3a29173c6d-fm-20231031.005-g3a29173c
MIME-Version: 1.0
Message-Id: <c10c558e-c2cc-40f0-b0b8-38d1e806e2f1@app.fastmail.com>
In-Reply-To: <ZVLDqJE8jCrjmnnP@momjian.us>
References: <20180622.172132.230342845.horiguchi.kyotaro@lab.ntt.co.jp>
 <ZVLDqJE8jCrjmnnP@momjian.us>
Date: Fri, 17 Nov 2023 15:39:14 -0300
From: "Euler Taveira" <euler@eulerto.com>
To: "Bruce Momjian" <bruce@momjian.us>,
 "Kyotaro HORIGUCHI" <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Lifetime of commit timestamps
Content-Type: multipart/alternative;
 boundary=44e355d3653143a8a9a1a752cd0b7994
Archived-At: <https://www.postgresql.org/message-id/c10c558e-c2cc-40f0-b0b8-38d1e806e2f1%40app.fastmail.com>
Precedence: bulk

--44e355d3653143a8a9a1a752cd0b7994
Content-Type: text/plain

On Mon, Nov 13, 2023, at 9:47 PM, Bruce Momjian wrote:
> Is this documentation change still relevant?

I think so. AFAICS nothing changed. Unless you read the source code, it is not
clear that VACUUM removes the information for frozen tuples. They are decoupled
(but executed in the same routine for convenience), hence, someone can ask why
the pg_xact_commit_timestamp() returns NULL for a transaction that was executed
*after* you enable track_commit_timestamp. The answer is the design used a
existing mechanism to clean up data in order to avoid creating a new one.


--
Euler Taveira
EDB   https://www.enterprisedb.com/

--44e355d3653143a8a9a1a752cd0b7994
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Mon, Nov 13,=
 2023, at 9:47 PM, Bruce Momjian wrote:<br></div><blockquote type=3D"cit=
e" id=3D"qt" style=3D""><div>Is this documentation change still relevant=
?<br></div></blockquote><div><br></div><div>I think so. AFAICS nothing c=
hanged. Unless you read the source code, it is not<br></div><div>clear t=
hat VACUUM removes the information for frozen tuples. They are decoupled=
<br></div><div>(but executed in the same routine for convenience), hence=
, someone can ask why<br></div><div>the pg_xact_commit_timestamp() retur=
ns NULL for a transaction that was executed<br></div><div>*after* you en=
able track_commit_timestamp. The answer is the design used a<br></div><d=
iv>existing mechanism to clean up data in order to avoid creating a new =
one.<br></div><div><br></div><div><br></div><div id=3D"sig112409080"><di=
v class=3D"signature">--<br></div><div class=3D"signature">Euler Taveira=
<br></div><div class=3D"signature">EDB&nbsp;&nbsp; <a href=3D"https://ww=
w.enterprisedb.com/">https://www.enterprisedb.com/</a><br></div></div><d=
iv><br></div></body></html>
--44e355d3653143a8a9a1a752cd0b7994--