On 3/20/13 8:41 AM, Bruce Momjian wrote:
On Mon, Mar 18, 2013 at 01:52:58PM -0400, Bruce Momjian wrote:
I assume a user would wait until they suspected corruption to turn it
on, and because it is only initdb-enabled, they would have to
dump/reload their cluster. The open question is whether this is a
usable feature as written, or whether we should wait until 9.4.
pg_upgrade can't handle this because the old/new clusters would have the
same catalog version number and the tablespace directory names would
conflict. Even if they are not using tablespaces, the old heap/index
files would not have checksums and therefore would throw an error as
soon as you accessed them. In fact, this feature is going to need
pg_upgrade changes to detect from pg_controldata that the old/new
clusters have the same checksum setting.
A few more issues with pg_upgrade: if we ever decide to change the
checksum calculation in a later major release, pg_upgrade might not work
because of the checksum change but could still work for users who don't
use checksums.
Also, while I understand why we have to set the checksum option at
initdb time, it seems we could enable users to turn it off after initdb
--- is there any mechanism for this?
Also, if a users uses checksums in 9.3, could they initdb without
checksums in 9.4 and use pg_upgrade? As coded, the pg_controldata
checksum settings would not match and pg_upgrade would throw an error,
but it might be possible to allow this, i.e. you could go from checksum
to no checksum initdb clusters, but not from no checksum to checksum. I
am wondering if the patch should reflect this.
If the docs don't warn about this, they should, but I don't think it's the
responsibility of this patch to deal with that problem. The reason I don't
believe this patch should deal with it is because that is a known, rather
serious, limitation of pg_upgrade. It's something about pg_upgrade that just
needs to be fixed, regardless of what patches might make the situation worse.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
