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

From Alexander Korotkov
Subject Re: Challenges preventing us moving to 64 bit transaction id (XID)?
Date
Msg-id CAPpHfdvHV3v=k7ZjYV24bo74x1akfD3f4FNS4bn5hZBGkAJp0Q@mail.gmail.com
Whole thread Raw
In response to Re: Challenges preventing us moving to 64 bit transaction id (XID)?  (Ryan Murphy <ryanfmurphy@gmail.com>)
Responses Re: Challenges preventing us moving to 64 bit transaction id (XID)?
List pgsql-hackers
Hi, Ryan!

On Sat, Jan 6, 2018 at 10:10 PM, Ryan Murphy <ryanfmurphy@gmail.com> wrote:
Thanks for this contribution!
I think it's a hard but important problem to upgrade these xids.

Unfortunately, I've confirmed that this patch 0001-64bit-guc-relopt-3.patch doesn't apply correctly on my computer.

Here's what I did:

I did a "git pull" to the current HEAD, which is 6271fceb8a4f07dafe9d67dcf7e849b319bb2647

Then I attempted to apply the patch, here's what I saw:

$ git apply patches/0001-64bit-guc-relopt-3.patch
error: src/backend/access/common/reloptions.c: already exists in working directory
error: src/backend/utils/misc/guc.c: already exists in working directory
error: src/include/access/reloptions.h: already exists in working directory
error: src/include/utils/guc.h: already exists in working directory
error: src/include/utils/guc_tables.h: already exists in working directory

Alexander, what is the process you're using to create the patch?  I've heard someone (maybe Tom Lane?) say that he sometimes uses "patch" directly instead of "git" to create the patch, with better results.  I forget the exact command.

I've created patches using context diff, as described in PostgreSQL wiki.
I already noticed that it causing troubles to some community members who use 'git apply'.  And also I noticed that majority of patches nowadays are sent using universal format.  So, I decided to switch to universal format too.  I'm working on rebasing patchset, that takes some time...  Next revision will be sent in universal format.

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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parallel append plan instability/randomness
Next
From: Tom Lane
Date:
Subject: Re: Parallel append plan instability/randomness