Re: Transaction ID wraparound: problem and proposed solution

> One idea I had from this is actually truncating pg_log at some point if
> we know all the tuples have the special committed xid.  It would prevent
> the file from growing without bounds.

Not truncating, but implementing pg_log as set of files - we could remove
files for old xids.

> Vadim, can you explain how WAL will make pg_log unnecessary someday?

First, I mentioned only that having undo we could remove old pg_log after
postmaster startup because of only committed changes would be in data
files and they would be visible to new transactions (small changes in tqual
will be required to take page' startup id into account) which would reuse xids.
While changing a page first time in current startup, server would do exactly
what Tom is going to do at vacuuming - just update xmin/xmax to "1" in all items
(or setting some flag in t_infomask), - and change page' startup id to current.

I understand that this is not complete solution for xids problem, I just wasn't
going to solve it that time. Now after Tom' proposal I see how to reuse xids
without vacuuming (but having undo): we will add XidWrapId (XWI) - xid wrap
counter - to pages and set it when we change page. First time we do this for
page with old XWI we'll mark old items (to know later that they were changed
by xids with old XWI). Each time we change page we can mark old xmin/xmax
with xid <= current xid as committed long ago (basing on xact TTL restrinctions).

All above assumes that there will be no xids from aborted transactions in pages,
so we need not lookup in pg_log to know is a xid committed/aborted, - there will
be only xids from running or committed xactions there.

And we need in undo for this.

Vadim