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 →
-
Wakeup WALWriter as needed for asynchronous commit performance.
- 4de82f7d7c50 9.2.0 cited
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