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
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 |