MIME-Version: 1.0
References: <182311743703924@mail.yandex.ru> <OSCPR01MB1496660969357E7D16EF4FF12F5E6A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <5381759333107@mail.yandex.ru> <OSCPR01MB14966B4CAB3CC8AE5F8DAD57FF5E7A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <CAA4eK1+Zayox=x84upet_gc4hrCKSwZSpnO9=Q4vH8rrJbsBOg@mail.gmail.com>
 <CACG=ezaFdL4EM8bdrHTRVHt5BmxxWGXcPiDr6Qm00Qj+S_Y+vQ@mail.gmail.com>
 <56771759769555@mail.yandex.ru> <OSCPR01MB14966A30D6251B0AE867FEE54F5E0A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <132271759810943@mail.yandex.ru> <OSCPR01MB14966709F525419547BA3F99DF5E0A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <1809191759818745@mail.yandex.ru> <OSCPR01MB14966359349E2A205DFB2D6CAF5EEA@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <545321760005292@mail.yandex.ru> <OSCPR01MB14966282B927E003022710B76F5EBA@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <689211760456931@mail.yandex.ru> <OSCPR01MB14966D4347F7C83697B074223F5E8A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <TY7PR01MB14554CC93E03A125BEE334C1EF586A@TY7PR01MB14554.jpnprd01.prod.outlook.com>
 <CAA4eK1KMuhaH=QgzJCwQgawuybosq-JMWWT9qSqyMZNV1MWjtg@mail.gmail.com> <OS9PR01MB121493384C07100ED5AF5E1E6F568A@OS9PR01MB12149.jpnprd01.prod.outlook.com>
In-Reply-To: <OS9PR01MB121493384C07100ED5AF5E1E6F568A@OS9PR01MB12149.jpnprd01.prod.outlook.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Fri, 20 Feb 2026 17:04:52 +0530
Message-ID: <CAA4eK1JFtm45nqE_4f=tJPsvLoAssSBA-RUqkPGhSZbQ7vSZ=g@mail.gmail.com>
Subject: Re: Patch for migration of the pg_commit_ts directory
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: ls7777 <ls7777@yandex.ru>, 
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "orlovmg@gmail.com" <orlovmg@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAA4eK1JFtm45nqE_4f%3DtJPsvLoAssSBA-RUqkPGhSZbQ7vSZ%3Dg%40mail.gmail.com>
Precedence: bulk

On Fri, Feb 20, 2026 at 4:35=E2=80=AFPM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> > One of
> > the use case I recall is to detect conflicts with accuracy after
> > upgrade. See docs [1] ("Commit timestamps and origin data are not
> > preserved during the upgrade. ..) I think this note needs an update
> > after this patch.
>
> Right, and code comments [a] should be also updated.
>

So, leaving aside update_delete, copying commit_ts could be helpful to
detect some other conflicts. You may want to once test the same and
show it here as part of use case establishment.

> BTW, is there a possibility that we can export and import xmin of the con=
flict
> slot to retain dead tuples even after the upgrade? Of course it's out-of-=
scope
> from this thread.
>

Yeah, this is a good point to explore separately. The key thing we
need to evaluate is whether the rows corresponding to old_xids are
retained. We probably need to evaluate the epoch part as well in old
cluster's slot. We do call set_frozenxids() for new cluster that might
have some impact on the functionality you are looking at.

> > Also, _on in the variable name appears bit odd.
>
> I have two options, thought?
>  - commit_ts_is_enabled,

This looks reasonable to me.

--=20
With Regards,
Amit Kapila.