Greg Stark wrote:
> On Thu, Jun 3, 2010 at 11:41 AM, Greg Stark <gsstark@mit.edu> wrote:
> > I think to make it work you need to store a whole 64-bit reference
> > transaction id consisting of both a cycle counter and a transaction
> > id. The invariant for the page is that every xid on the page can be
> > compared to that reference transaction id using normal transactionid
> > semantics. Actually I think the easiest way to do that is to set it to
> > the oldest xid on the page. The first thing to do before comparing any
> > transaction id on the page with a real transaction id would be to
> > figure out whether the reference xid is comparable to the live xid,
> > which if it's the oldest xid on the page implies they'll all be
> > comparable.
> >
> > The way to maintain that invariant would be that any xid insertion on
> > the page must advance the reference xid if it's not comparable to the
> > newly inserted xid. It has to be advanced to the oldest xid that's
> > still comparable with the newly inserted xid. Any xids on the page
> > that are older than the new refernce xid have to be frozen or removed.
> > I'm not sure how to do that without keeping clog forever though.
>
> So the more I think about this the more I think it's unavoidable that
> we would need to retain clog forever.
>
> I think the goal here is to be able to load data into the database and
> then never write the data ever again. Even if you visit the page years
> later after the transaction ids have wrapped around several times. In
> that case there's no avoiding that you'll need to know whether that
> transaction committed or aborted.
I think we might need two bits, one commited and all visible, and
another aborted and all vislble.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ None of us is going to be here forever. +