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 > wrote: 0002-heap-page-special-1.patch Putting xid and multixact bases into PageHeaderData would take extra 16 bytes

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

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

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)

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 >>>

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

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 >>>

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

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

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

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

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:

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

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

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

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

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” >>

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