From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: manipulating pg_control file from Perl |
Date: | 2025-03-13 20:42:32 |
Message-ID: | 2929650.1741898552@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aleksander Alekseev <aleksander(at)timescale(dot)com> writes:
> Previously it was pointed out [1] that manipulating the pg_control
> file from Cluster.pm may be beneficial under certain conditions.
> As an example, one can downgrade the catalog version in pg_control,
> place input files for pg_upgrade, execute pg_upgrade and check the
> results. This would allow writing TAP-tests for pg_upgrade easily, in
> some cases at least. Perhaps there are other scenarios.
I'm finding it *really* hard to buy that as a credible use-case.
There is no situation where changing the catalog version in
pg_control, by itself, is a useful thing to do: you'd have to also
install matching catalog contents. But then wherever you got the
catalog contents from would be a perfectly good source for a matching
pg_control, no? Likewise, the idea that pg_control should be
architecture-independent when none of the catalogs or data files are
seems pretty pointless.
Maybe there's a case to be made for doing something here, but you
haven't made it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2025-03-13 21:36:22 | Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility. |
Previous Message | Melanie Plageman | 2025-03-13 20:34:12 | Re: BitmapHeapScan streaming read user and prelim refactoring |