On Mon, Feb 6, 2012 at 10:02 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > 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.
We wouldn't need to do that would we? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
