Re: Patch for migration of the pg_commit_ts directory
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
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>
Date: 2026-02-20T11:34:52Z
Lists: pgsql-hackers
On Fri, Feb 20, 2026 at 4:35 PM 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 conflict
> 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.
--
With Regards,
Amit Kapila.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Update copyright for 2026
- 451c43974f8e 19 (unreleased) cited