RE: Patch for migration of the pg_commit_ts directory

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'ls7777' <ls7777(at)yandex(dot)ru>, "orlovmg(at)gmail(dot)com" <orlovmg(at)gmail(dot)com>, "amit(dot)kapila16(at)gmail(dot)com" <amit(dot)kapila16(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Patch for migration of the pg_commit_ts directory
Date: 2025-10-07 03:15:18
Message-ID: OSCPR01MB14966A30D6251B0AE867FEE54F5E0A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Thanks for updating the patch.

Regarding the check_track_commit_timestamp_parameter(), I'm not sure the function
is needed. Since pg_controldata outputs whether the commit_ts module is enabled
or not [1], can we obtain there instead?
I imagined like we can add a new field at ControlData, it could be obtained in get_control_data(),
values for instances could be compared in check_control_data().

Another possibility is that oldestCommitTsXid/newestCommitTsXid can be always
valid if track_commit_timestamp is on. In this case the attribute is not needed
anymore. It is enough to check these values. Can you check them?

Regarding the test, I feel it is unnecessary long. I feel it is enough to ensure
one or two transactions have the same timestamp on the both nodes, pgbench is not
needed. Current test may not be able to finish on the slow machine.

[1]
```
$ pg_controldata data/ | grep "track_"
track_commit_timestamp setting: off
```

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-10-07 04:06:43 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Previous Message Peter Smith 2025-10-07 03:12:06 Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE