Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)? - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)?
Date
Msg-id CAPpHfdvijTVc7eMLr=HMxyV+0kgtOme84TfdOM7VEHfcc97peg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)?  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
On Tue, Jun 6, 2017 at 4:05 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.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
 

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [HACKERS] [PATCH] Fixed malformed error message on malformed SCRAM message.
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] PG10 transition tables, wCTEs and multiple operationson the same table