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: Jim Nasby <jim@nasby.net>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.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-03-01T00:48:47Z
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.

Jim Nasby <jim@nasby.net> writes:
> On 2/29/12 3:53 PM, Alvaro Herrera wrote:
>> .. in fact this is precisely what killed Zdenek Kotala's idea of
>> upgrading.

> This is also why Simon has avoided the whole upgrade thing with his 16 bit checksum idea (otherwise presumably we'd be looking at bigger checksums anyway).

> I get that fussing around with the version field is ugly. If there was another way to do this without breaking pg_upgrade then it would be silly to mess with the version field. Unfortunately, there is no other way.

Fundamentally, what is going on here is that several of us think that we
need a page format upgrade infrastructure first, and then we can think
about adding checksums.  Simon would like to cram checksums in without
building such infrastructure, regardless of the consequences in code
ugliness or future maintainability.  Personally, I think that is a bad
tradeoff.  Eventually we are going to have to build that infrastructure,
and the more we've kluged the page header format in the meanwhile, the
more unpleasant it's going to be.

			regards, tom lane