Re: Patch for migration of the pg_commit_ts directory

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: ls7777 <ls7777(at)yandex(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "orlovmg(at)gmail(dot)com" <orlovmg(at)gmail(dot)com>
Subject: Re: Patch for migration of the pg_commit_ts directory
Date: 2026-02-20 07:58:39
Message-ID: CAA4eK1KMuhaH=QgzJCwQgawuybosq-JMWWT9qSqyMZNV1MWjtg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 5, 2026 at 1:54 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> I found that v7 needs rebased. Copyright was also updated in the attached patch.
> I'm not the author of the patch though.
>

Can we update the use case of this patch in the commit message? 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.

res = executeQueryOrDie(conn, "SELECT setting FROM pg_settings "
+ "WHERE name = 'track_commit_timestamp'");
+ track_commit_timestamp_on = strcmp(PQgetvalue(res, 0, 0), "on") == 0;

As this is a boolean variable, what if the user sets the value of this
GUC as true, will the above work correctly? Also, _on in the variable
name appears bit odd.
--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2026-02-20 08:21:05 Re: refactor architecture-specific popcount code
Previous Message Hüseyin Demir 2026-02-20 06:52:33 Re: BUG #19393: pg_upgrade fails with duplicate key violation when CHECK constraint named *_not_null exists