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

Hi Alexander, On 22.06.2017 18:36, Alexander Korotkov wrote: On Wed, Jun 7, 2017 at 11:33 AM, Alexander Korotkov mailto:a.korot...@postgrespro.ru>> wrote: 0002-heap-page-special-1.patch Putting xid and multixact bases into PageHeaderData would take extra 16 bytes on index pages too. That wou

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

On Thu, Jul 6, 2017 at 07:29:07AM -0700, Jim Finnerty wrote: > re: "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." I am coming to this very late, but wouldn't such a row be marked using our frozen-commited

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

On 6 July 2017 at 15:29, Jim Finnerty wrote: > > Feel free to knock down this 'straw man' and propose something better! I think the pattern in this design that we don't want is that it imposes extra complexity on every user of every page even when the page doesn't have the problem and even when t

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

On Wed, Jun 7, 2017 at 12:49 PM, Andres Freund wrote: > On 2017-06-07 07:49:00 -0300, Alvaro Herrera wrote: >> Instead of adding a second 64 bit counter for multixacts, how about >> first implementing something like TED which gets rid of multixacts (and >> freezing thereof) altogether? > > -1 - th

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

On 2017-06-07 07:49:00 -0300, Alvaro Herrera wrote: > Instead of adding a second 64 bit counter for multixacts, how about > first implementing something like TED which gets rid of multixacts (and > freezing thereof) altogether? -1 - that seems like a too high barrier. We've punted on improvements

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

On Wed, Jun 7, 2017 at 4:47 PM, Heikki Linnakangas wrote: > On 06/06/2017 07:24 AM, Ashutosh Bapat wrote: >> >> On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer >> wrote: >>> >>> On 6 June 2017 at 12:13, Ashutosh Bapat >>> wrote: >>> What happens when the epoch is so low that the rest of the XI

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

Alexander Korotkov wrote: > Right. I used the term "64-bit epoch" during developer unconference, but > that was ambiguous. It would be more correct to call it a "64-bit base". > BTW, we will have to store two 64-bit bases: for xids and for multixacts, > because they are completely independent co

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

On Wed, Jun 7, 2017 at 10:47 AM, Heikki Linnakangas wrote: > On 06/06/2017 07:24 AM, Ashutosh Bapat wrote: > >> On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer >> wrote: >> >>> On 6 June 2017 at 12:13, Ashutosh Bapat >>> wrote: >>> >>> What happens when the epoch is so low that the rest of the XID

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

On Tue, Jun 6, 2017 at 4:05 PM, Peter Eisentraut < peter.eisentr...@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 p

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

On 06/06/2017 07:24 AM, Ashutosh Bapat wrote: On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer wrote: On 6 June 2017 at 12:13, Ashutosh Bapat wrote: What happens when the epoch is so low that the rest of the XID does not fit in 32bits of tuple header? Or such a case should never arise? Storing

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

On Tue, Jun 6, 2017 at 09:05:03AM -0400, Peter Eisentraut 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

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

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

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

On Tue, Jun 6, 2017 at 06:00:54PM +0800, Craig Ringer wrote: > On 6 June 2017 at 12:38, Ashutosh Bapat > wrote: > > On Tue, Jun 6, 2017 at 10:00 AM, Tom Lane wrote: > >> In my mind the harder problem is where to find another 32 bits for the > >> new page header field. You could convert the hea

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

On 6 June 2017 at 12:38, Ashutosh Bapat wrote: > On Tue, Jun 6, 2017 at 10:00 AM, Tom Lane wrote: >> Ashutosh Bapat writes: >>> On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer wrote: Storing an epoch implies that rows can't have (xmin,xmax) different by more than one epoch. So if you're

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

On Tue, Jun 6, 2017 at 10:00 AM, Tom Lane wrote: > Ashutosh Bapat writes: >> On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer wrote: >>> Storing an epoch implies that rows can't have (xmin,xmax) different by >>> more than one epoch. So if you're updating/deleting an extremely old >>> tuple you'll pr

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

Ashutosh Bapat writes: > On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer wrote: >> Storing an epoch implies that rows can't have (xmin,xmax) different by >> more than one epoch. So if you're updating/deleting an extremely old >> tuple you'll presumably have to set xmin to FrozenTransactionId if it >

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

On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer wrote: > On 6 June 2017 at 12:13, Ashutosh Bapat > wrote: > >> What happens when the epoch is so low that the rest of the XID does >> not fit in 32bits of tuple header? Or such a case should never arise? > > Storing an epoch implies that rows can't ha

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

On 6 June 2017 at 12:13, Ashutosh Bapat wrote: > What happens when the epoch is so low that the rest of the XID does > not fit in 32bits of tuple header? Or such a case should never arise? Storing an epoch implies that rows can't have (xmin,xmax) different by more than one epoch. So if you're up

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

On Mon, Jun 5, 2017 at 2:38 PM, Heikki Linnakangas wrote: > On 06/05/2017 11:49 AM, Tianzhou Chen wrote: >> >> Hi Pg Hackers, >> >> XID wraparound seems to be quite a big concern and we introduce >> changes like “adding another frozen bit to each page” >> [http://rhaas.blogspot.com/2016/03/no-more

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

On 06/05/2017 11:49 AM, Tianzhou Chen wrote: Hi Pg Hackers, XID wraparound seems to be quite a big concern and we introduce changes like “adding another frozen bit to each page” [http://rhaas.blogspot.com/2016/03/no-more-full-table-vacuums.html

[HACKERS] Challenges preventing us moving to 64 bit transaction id (XID)?

Hi Pg Hackers, XID wraparound seems to be quite a big concern and we introduce changes like “adding another frozen bit to each page” [http://rhaas.blogspot.com/2016/03/no-more-full-table-vacuums.html to tackle this. I am j