Re: Challenges preventing us moving to 64 bit transaction id (XID)?

On Tue, Jun 6, 2017 at 4:05 PM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> On 6/6/17 08:29, Bruce Momjian wrote:
> > On Tue, Jun 6, 2017 at 06:00:54PM +0800, Craig Ringer wrote:
> >> Tom's point is, I think, that we'll want to stay pg_upgrade
> >> compatible. So when we see a pg10 tuple and want to add a new page
> >> with a new page header that has an epoch, but the whole page is full
> >> so there isn't 32 bits left to move tuples "down" the page, what do we
> >> do?
> >
> > I guess I am missing something. If you see an old page version number,
> > you know none of the tuples are from running transactions so you can
> > just freeze them all, after consulting the pg_clog. What am I missing?
> > If the page is full, why are you trying to add to the page?
>
> The problem is if you want to delete from such a page. Then you need to
> update the tuple's xmax and stick the new xid epoch somewhere.
>
> We had an unconference session at PGCon about this. These issues were
> all discussed and some ideas were thrown around. We can expect a patch
> to appear soon, I think.
>

Right. I'm now working on splitting my large patch for 64-bit xids into
patchset.
I'm planning to post patchset in the beginning of next week.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company