RE: Patch for migration of the pg_commit_ts directory - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Patch for migration of the pg_commit_ts directory
Date
Msg-id OS9PR01MB1214994DCC48AF5C0503E5F7AF5082@OS9PR01MB12149.jpnprd01.prod.outlook.com
Whole thread
In response to RE: Patch for migration of the pg_commit_ts directory  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
Dear Sergey,

While considering the feature once again, I came up with another issue.

When pg_upgrade migrates objects to a new instance, it normally checks whether
the new instance does not have existing objects. E.g., check_new_cluster_is_empty()
checks if no tables exist, and check_new_cluster_replication_slots() ensures
there are no logical slots.

Based on that, how should we handle the commit timestamp? Since the patch simply
copies the pg_commit_ts subdir, existing entries in the new cluster will be overwritten.
So we may have to check if the commit_ts entries are empty when the pg_upgrade
command runs, but not sure how to do that.

Best regards,
Hayato Kuroda
FUJITSU LIMITED
 

pgsql-hackers by date:

Previous
From: SATYANARAYANA NARLAPURAM
Date:
Subject: Re: [PATCH] Release replication slot on error in SQL-callable slot functions
Next
From: Peter Smith
Date:
Subject: Re: Include schema-qualified names in publication error messages.