| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Checksums, state of play |
| Date: | 2012-03-06 18:03:43 |
| Message-ID: | 2384.1331057023@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> That's not why I want to leave that field alone, though: I want to
> leave that field alone for backward and forward compatibility, so that
> any version of community PostgreSQL ever released - and any page
> inspection tools, current or future - can look at the low-order byte
> of that field and know what page version they've got.
I've not been following this thread very closely, but FWIW I find the
above argument extremely compelling. We could get away with relocating
the version identifier in the narrow context of an upgrade from PG 9.x
to 9.y, but the side effects for external tools such as pg_filedump
would be disastrous.
(And yeah, as maintainer for pg_filedump I'm rather biased.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2012-03-06 18:14:57 | Re: elegant and effective way for running jobs inside a database |
| Previous Message | Simon Riggs | 2012-03-06 18:00:13 | Re: Checksums, state of play |