On 06.02.2012 10:05, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
On 06.02.2012 05:48, Bruce Momjian wrote:
Thanks. Clearly we don't need 16 bits to represent our page version
number because we rarely change it. The other good thing is I don't
remember anyone wanting additional per-page storage in the past few
years except for a checksum.
There's this idea that I'd like to see implemented:
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01176.php
As you'll note, adding that field will change the page format and is
therefore ruled out for 9.2.
ISTM there is a different way to handle that anyway. All we need to do
is to record the LSN of the last wraparound in shared memory/control
file. Any block with page LSN older than that has all-frozen rows.
That doesn't use any space nor does it require another field to be
set.
Good idea. However, the followup idea to that discussion was to not only
avoid the I/O needed to mark tuples as frozen, but to avoid xid
wraparound altogether, by allowing clog to grow indefinitely. You do
want to freeze at some point of course, to truncate the clog, but it
would be nice to not have a hard limit. The way to do that is to store
an xid "epoch" in the page header, so that Xids are effectively 64-bits
wide, even though the xid fields on the tuple header are only 32-bits
wide. That does require a new field in the page header.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
