Re: Checksums, state of play
От | Simon Riggs |
---|---|
Тема | Re: Checksums, state of play |
Дата | |
Msg-id | CA+U5nMKXUAWRKezQ70iyYJO9J-iDQsNCZezisi14Dj3imYe+1A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Checksums, state of play (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Checksums, state of play
|
Список | 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 по дате отправления: