Re: Patch for migration of the pg_commit_ts directory

From: ls7777 <ls7777(at)yandex(dot)ru>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "orlovmg(at)gmail(dot)com" <orlovmg(at)gmail(dot)com>, "amit(dot)kapila16(at)gmail(dot)com" <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: Patch for migration of the pg_commit_ts directory
Date: 2026-03-27 15:16:25
Message-ID: 53871774622072@mail.yandex.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

<div>Hi,</div><div> </div><div><div>Why do I need the --pg-commit-ts key?</div><div>1. Users who do not need to migrate the pg_commit_ts directory (regardless of the value of the pg_commit_timestamp parameter) will receive the usual pg_upgrade behavior.</div><div>2. Users who need to move pg_commit_ts directory may already have their own scripts for copying pg_commit_ts directory, and decide to continue using them. There will also be no surprises for them when using pg_upgrage.</div><div>3. pg_commit_ts migration turned out to be more complicated than I expected. And the pg_replication_origin migration was affected. I did the migration the way I can (update tables), but it's architecturally incorrect. Therefore, using the command line key can be used as a temporary solution that will be removed after creating an architecturally correct solution.</div></div><div> </div><div><div>If the current solution with update pg_replication_origin is not suitable. I will remove these updates and will not migrate pg_commit_ts if there is a non-empty pg_replication_origin in the old cluster. After migration, the user should not receive conflict messages. This may give the impression of an erroneous migration.</div><div>I would like to keep the command line key.</div></div><div> </div><div>----------------</div><div>Кому: 'ls7777' (ls7777(at)yandex(dot)ru), Masahiko Sawada (sawada(dot)mshk(at)gmail(dot)com);</div><div>Копия: pgsql-hackers(at)postgresql(dot)org, orlovmg(at)gmail(dot)com, amit(dot)kapila16(at)gmail(dot)com;</div><div>Тема: Patch for migration of the pg_commit_ts directory;</div><div>27.03.2026, 07:12, "Hayato Kuroda (Fujitsu)" &lt;kuroda(dot)hayato(at)fujitsu(dot)com&gt;:</div><blockquote><p>Dear Sergey,<br /><br />Sorry for being late, I was busy in another project.<br />Not sure we have enough time to rush this for PG19 because some new parts are<br />added recently.<br /><br />Personally considered, the patch might be able to separate into two parts.<br />0001 contains changes to migrate the replication origin, and 0002 contains to<br />migrate the commit_ts directory. For 0001, we may need a new SQL function to<br />migrate replication origins, and it could be used only while in the binary upgrade<br />mode like binary_upgrade_add_sub_rel_state(). We must not directly update the<br />system catalog via UPDATE command. 0002 might be the same as what we discussed<br />earlier.<br /> </p><blockquote> 1. Added the --pg-commit-ts command line key for pg_upgrade.<br /> Migration of the pg_commit_ts directory will be performed only if the user explicitly wishes.</blockquote><p><br />I cannot find the reason why you changed here. Can you share me your opinion?<br /><br /><br />Best regards,<br />Hayato Kuroda<br />FUJITSU LIMITED<br /> </p></blockquote>

Attachment Content-Type Size
unknown_filename text/html 2.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-03-27 15:18:29 Re: another autovacuum scheduling thread
Previous Message Peter Eisentraut 2026-03-27 15:08:20 Re: Align tests for stored and virtual generated columns