Re: 16-bit page checksums for 9.2

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Josh Berkus <josh@agliodbs.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-02T01:46:18Z
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.

On Thu, Mar 1, 2012 at 8:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Excerpts from Robert Haas's message of jue mar 01 21:23:06 -0300 2012:
>>> and that, further, you were arguing that we should not support
>>> multiple page versions.
>
>> I don't think we need to support multiple page versions, if multiple
>> means > 2.
>
> That's exactly the point here.  We clearly cannot support on-line
> upgrade unless, somewhere along the line, we are willing to cope with
> two page formats more or less concurrently.  What I don't want is for
> that requirement to balloon to supporting N formats forever.  If we
> do not have a mechanism that allows certifying that you have no
> remaining pages of format N-1 before you upgrade to a server that
> supports (only) versions N and N+1, then we're going to be in the
> business of indefinite backwards compatibility instead.
>
> I'm not entirely sure, but I think we may all be in violent agreement
> about where this needs to end up.

I was using multiple to mean N>1, so yeah, it's sounding like we're
more or less on the same page here.

One thing I'm not too sure about is how to extend the page format to
handle optional features.  For example, suppose we want to add 2 bytes
to the page header for a checksum (or 4 bytes, or any other number).
Ideally, I'd like to not use up those 2 bytes on pages that aren't
checksummed.  What do we do about that?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company