Re: [DESIGN] Incremental checksums
От | Jim Nasby |
---|---|
Тема | Re: [DESIGN] Incremental checksums |
Дата | |
Msg-id | 55A424A4.7040409@BlueTreble.com обсуждение исходный текст |
Ответ на | [DESIGN] Incremental checksums (David Christensen <david@endpoint.com>) |
Ответы |
Re: [DESIGN] Incremental checksums
Re: [DESIGN] Incremental checksums |
Список | pgsql-hackers |
On 7/13/15 3:26 PM, David Christensen wrote: > * Incremental Checksums > > PostgreSQL users should have a way up upgrading their cluster to use data checksums without having to do a costly pg_dump/pg_restore;in particular, checksums should be able to be enabled/disabled at will, with the database enforcing thelogic of whether the pages considered for a given database are valid. > > Considered approaches for this are having additional flags to pg_upgrade to set up the new cluster to use checksums wherethey did not before (or optionally turning these off). This approach is a nice tool to have, but in order to be ableto support this process in a manner which has the database online while the database is going throught the initial checksumprocess. It would be really nice if this could be extended to handle different page formats as well, something that keeps rearing it's head. Perhaps that could be done with the cycle idea you've described. Another possibility is some kind of a page-level indicator of what binary format is in use on a given page. For checksums maybe a single bit would suffice (indicating that you should verify the page checksum). Another use case is using this to finally ditch all the old VACUUM FULL code in HeapTupleSatisfies*(). -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: