Horton

Re: 16-bit page checksums for 9.2

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Alvaro Herrera <alvherre@commandprompt.com>, Simon Riggs <simon@2ndquadrant.com>, Noah Misch <noah@leadboat.com>, Andres Freund <andres@anarazel.de>, Kevin Grittner <kevin.grittner@wicourts.gov>, david <david@fetter.org>, aidan <aidan@highrise.ca>, stark <stark@mit.edu>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-29T22:52:34Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Wakeup WALWriter as needed for asynchronous commit performance.

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Feb 29, 2012 at 4:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Easier for who? I don't care for the idea of code that has to cope with
>> two page formats, or before long N page formats, because if we don't
>> have some mechanism like this then we will never be able to decide that
>> an old data format is safely dead.

> Huh?  You can drop support for a new page format any time you like.
> You just decree that version X+1 no longer supports it, and you can't
> pg_upgrade to it until all traces of the old page format are gone.

And how would a DBA know that?

> If you're going to require an offline rewrite of the whole old cluster
> before doing the upgrade, how much better is it than just breaking the
> page format and telling pg_upgrade users they're out of luck?

The difference is that people aren't playing russian roulette with their
data when they upgrade.  The point of the mechanisms being discussed
here is to know, for certain, that a large database no longer contains
pages of the old format.

			regards, tom lane