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

On Tue, Jan 9, 2018 at 12:41 AM, Alexander Korotkov <
a(dot)korotkov(at)postgrespro(dot)ru> wrote:

> On Sat, Jan 6, 2018 at 10:10 PM, Ryan Murphy <ryanfmurphy(at)gmail(dot)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.
> https://wiki.postgresql.org/wiki/Working_with_Git#Context_diffs_with_Git
> 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.
>

Please, find in attachment the rebased patchset.

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