Re: Fail to create PK or index for large table in Windows

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Pavel <ospavelmail(at)gmail(dot)com>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Fail to create PK or index for large table in Windows
Date: 2018-11-16 01:10:38
Message-ID: CAEepm=26wnyxo+i79ZMpz-+=mVVu_a31Y-jfE58-x-9JZqN-MQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Nov 13, 2018 at 10:57 PM Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> Oh, I think I just understood the root bug. It looks like a stupid
> "large file" problem, 32 bit off_t being overflowed. I'll keep the
> discussion off that over on the other thread. I posted a patch on
> that thread; if you're able to recompile PostgreSQL, it'd be great if
> you could test it. Otherwise, no worries.

Pavel offered privately to test the change if I could supply a build.
I tried asking AppVeyor to build the current master branch as of a few
minutes ago and consider the "Release" directory to be an "artifact",
and amazingly it spat out a .zip file available for 6 months:

https://ci.appveyor.com/project/macdice/postgres/builds/20341645/artifacts

I'm not sure how easy this will be to work with if you're used to one
of those installers. Hopefully all the libraries needed are present
and you can just unzip it and run "initdb.exe -D pgdata",
"postgres.exe -D pgdata" -- but I have no personal experience of
PostgreSQL on Windows so I'm guessing here. Pavel, if you have time
to try testing the bug fix that was committed, that'd be great. If it
goes well, perhaps we could consider making bleeding edge builds
available all the time.

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2018-11-16 05:06:41 BUG #15509: Pg_Dump failed if Database name contains non ascii characters
Previous Message Melanie Plageman 2018-11-16 00:51:45 Re: BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE