Re: Checksums, state of play

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Checksums, state of play
Date: 2012-03-06 15:40:14
Message-ID: CA+U5nMKXUAWRKezQ70iyYJO9J-iDQsNCZezisi14Dj3imYe+1A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 6, 2012 at 2:25 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-03-06 15:47:46 Re: elegant and effective way for running jobs inside a database
Previous Message Tom Lane 2012-03-06 15:38:31 Re: Dropping PL language retains support functions