On Apr17, 2013, at 18:15 , Bruce Momjian <br...@momjian.us> wrote: > On Wed, Apr 17, 2013 at 05:28:06PM +0200, Florian Pflug wrote: >> However, you're right that time's running out. It'd be a shame though >> if we'd lock ourselves into CRC as the only available algorithm essentially >> forever. Is there any way we can change the checksum algorithm in 9.4 >> *without* breaking pg_upgrade? Maybe pd_pagesize_version could be used >> for that - we could make version 5 mean "just like version 4, but with >> a different checksum algorithm". Since the layout wouldn't actually >> chance, that'd be far easier to pull off than actually supporting multiple >> page layouts. If that works, then shipping 9.3 with CRC is probably >> the best solution. If not, we should see to it that something like Ants >> parallel version of FNV or a smallget into 9.3 if at all possible, >> IMHO. > > I was going to ask about the flexibility of pg_upgrade and checksums. > Right now you have to match the old and new cluster checksum modes, but > it seems it would be possible to allow pg_upgrade use from checksum to > no-checksum servers. Does the backend look at the pg_controldata setting, > or at the page checksum flag? If the former, it seems pg_upgrade could > run a a no-checksum server just fine that had checksum information on > its pages. This might give us more flexibility in changing the checksum > algorithm in the future, i.e. you only lose checksum ability.
AFAIK, there's currently no per-page checksum flag. Still, being only able to go from checksummed to not-checksummed probably is for all practical purposes the same as not being able to pg_upgrade at all. Otherwise, why would people have enabled checksums in the first place? best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
