Re: Challenges preventing us moving to 64 bit transaction id (XID)? - Mailing list pgsql-hackers

From Chris Travers
Subject Re: Challenges preventing us moving to 64 bit transaction id (XID)?
Date
Msg-id CAN-RpxBTHxNDbE0PO92k-akvRJndBQN=Z=ioGgJbHiW9-r+2Qg@mail.gmail.com
Whole thread Raw
In response to Re: Challenges preventing us moving to 64 bit transaction id (XID)?  (Andres Freund <andres@anarazel.de>)
Responses Re: Challenges preventing us moving to 64 bit transaction id (XID)?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers


On Fri, Mar 2, 2018 at 12:07 AM Andres Freund <andres@anarazel.de> wrote:
On 2018-03-02 01:56:00 +0300, Alexander Korotkov wrote:
> On Fri, Mar 2, 2018 at 1:51 AM, Andres Freund <andres@anarazel.de> wrote:
>
> > On 2018-03-02 01:48:03 +0300, Alexander Korotkov wrote:
> > > Also, the last commitfest is already too late for such big changes.
> > > So, I'm marking this RWF.
> >
> > Agreed.  Perhaps extract the 64bit GUC patch and track that separately?
> > Seems like something we should just do...
> >
>
> Sounds reasonable.  But I didn't notice if there are other users for 64bit
> GUCs besides 64bit xids?

I think there were a couple past occasions where we could've used that,
don't quite recall the details. We're at least not that far away from
the point where various size limits are actually limited by int32
range. And timeouts of ~25 days are long but not entirely unreasonable.

As a note here, I have worked on projects where there could be 2-week-long idle-in-transaction states (no joke, we tuned things to only use virtual xids for most of that time), and having an ability to set idle-in-transaction timeouts to figures of greater than a month are things I could imagine doing.  I would certainly favor the idea of 64-big GUC variables as a general rule.

Greetings,

Andres Freund



--
Best Regards,
Chris Travers
Head of Database

Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com 
Saarbrücker Straße 37a, 10405 Berlin

pgsql-hackers by date:

Previous
From: Chris Travers
Date:
Subject: Re: Prevent extension creation in temporary schemas
Next
From: Arthur Zakirov
Date:
Subject: Re: [PATCH] xlogreader: do not read a file block twice