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

From Ryan Murphy
Subject Re: Challenges preventing us moving to 64 bit transaction id (XID)?
Date
Msg-id 151526584358.1766.14918985281890942296.pgcf@coridan.postgresql.org
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)?
Re: Challenges preventing us moving to 64 bit transaction id (XID)?
List pgsql-hackers
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
sometimesuses "patch" directly instead of "git" to create the patch, with better results.  I forget the exact command.
 

For now I'm setting this to Waiting on Author, until we have a patch that applies via "git apply".

Thanks!
Ryan

The new status of this patch is: Waiting on Author

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Rangejoin rebased
Next
From: Ryan Murphy
Date:
Subject: Re: Add default role 'pg_access_server_files'