Re: Checksums, state of play - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Checksums, state of play
Date
Msg-id CA+U5nMKXUAWRKezQ70iyYJO9J-iDQsNCZezisi14Dj3imYe+1A@mail.gmail.com
Whole thread Raw
In response to Re: Checksums, state of play  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Checksums, state of play  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Mar 6, 2012 at 2:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> For the reasons stated above, I believe pd_tli is less useful than
> pd_pagesize_version.  I fear that if we repurpose pd_pagesize_version,
> we're going to make things very difficult for people who want to write
> block-inspection tools, like pg_filedump or pageinspect.  Right now,
> it's possible to look at that offset within the block and know for
> certain what page version you're dealing with.  If we repurpose it to
> hold checksum data, that will no longer be possible.  Unlike pd_tli,
> pd_pagesize_version is validated every time we read a block.

We've not changed the page format in 5 years. I really can't see what
the value of having a constant stored on every data block, especially
since you're now saying that we *shouldn't* bump the constant for this
change. Surely if we are keeping the pd_pagesize_version field its
obvious that we should increment it? If not, why the insistence on
keeping the field if we aren't using it for its stated purpose?

Do you know of any PostgreSQL variant that can set this byte range to
different values? If so, I'd suggest we just declare the field "user
defined" or some such so that others can use it for different things
as well and then use pd_tli.

IMHO if we keep use pd_tli but pd_pagesize_version then we should increment it.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Dropping PL language retains support functions
Next
From: Tom Lane
Date:
Subject: Re: elegant and effective way for running jobs inside a database