Fix excessive memory consumption in the new sort pre-reading code.
LogicalTapeRewind() should not allocate large read buffer, if the tape
is completely empty. The calling code relies on that, for its
calculation of how much memory to allocate for the read buffers. That
lead to massive overallocati
On 10/06/2016 04:23 AM, Peter Geoghegan wrote:
I noticed a simple oversight in this patch. It looks like you missed
one place where state->maxTapes ought to be replaced with
numInputTapes -- the loop that calls LogicalTapeAssignReadBufferSize()
needs that changed too, in order to continue to resp
Remove -Wl,-undefined,dynamic_lookup in macOS build.
We don't need this anymore, and it prevents build-time error checking
that's usually good to have, so remove it. Undoes one change of commit
cac765820.
Unfortunately, it's much harder to get a similar effect on other common
platforms, because
Try to fix python shlib probe for MinGW.
Per discussion with Andrew Dunstan, it seems there are three peculiarities
of the Python installation on MinGW (or at least, of the instance on
buildfarm member frogmouth). First, the library name doesn't contain
"2.7" but just "27". It looks like we can
On Mon, Oct 3, 2016 at 3:38 AM, Heikki Linnakangas
wrote:
> Change the way pre-reading in external sort's merge phase works.
I noticed a simple oversight in this patch. It looks like you missed
one place where state->maxTapes ought to be replaced with
numInputTapes -- the loop that calls LogicalT
Update obsolete comments and perldoc.
Loose ends from commit 2a0f89cd717ce6d49cdc47850577823682167e87.
Daniel Gustafsson
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/61f9e7ba3c4e4bde887f980b9316fb818ede59b6
Modified Files
--
src/test/perl/PostgresNod
Update obsolete comments and perldoc.
Loose ends from commit 2a0f89cd717ce6d49cdc47850577823682167e87.
Daniel Gustafsson
Branch
--
REL9_6_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/bfcd07bd8fdf1ddaba375aa5b3aea419a898
Modified Files
--
src/test/perl/Post
In python shlib probe, cater for OpenBSD, which omits the .so symlink.
Most Unix-oid platforms provide a symlink "libfoo.so" -> "libfoo.so.n.n"
to allow the linker to resolve a reference "-lfoo" to a version-numbered
shared library. OpenBSD has apparently hacked ld(1) to do this internally,
becau
I wrote:
> Andrew Dunstan writes:
>> Looks like there are still problems on Windows/mingw and OpenBSD - see
>> frogmouth and curculio on the buildfarm.
> Yeah. I just sent you an offlist request to look into what's happening
> on frogmouth, and I'm talking to curculio's owner as well.
The answ
Andrew Dunstan writes:
> Looks like there are still problems on Windows/mingw and OpenBSD - see
> frogmouth and curculio on the buildfarm.
Yeah. I just sent you an offlist request to look into what's happening
on frogmouth, and I'm talking to curculio's owner as well.
> Do we need to fall back
On 10/04/2016 04:38 PM, Tom Lane wrote:
Huh, we do need to look in $python_configdir for the Python shlib.
Debian does it that way, for no doubt what seems to them a good reason.
Thanks to Aidan Van Dyk for confirmation.
Looks like there are still problems on Windows/mingw and OpenBSD - s
On Wed, Oct 5, 2016 at 5:53 PM, Amit Kapila wrote:
> On Tue, Oct 4, 2016 at 8:32 PM, Robert Haas wrote:
>> Extend framework from commit 53be0b1ad to report latch waits.
>>
>
> I am facing windows below compilation error:
>
> 1>pgstat.h(726): warning C4005: 'WAIT_TIMEOUT' : macro redefinition
> 1>
Re-alphabetize #include directives.
Thomas Munro
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/eb3bc0bd1a68e30f09f36937da5aa5338b3b994c
Modified Files
--
src/backend/postmaster/bgworker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
S
On Tue, Oct 4, 2016 at 8:32 PM, Robert Haas wrote:
> Extend framework from commit 53be0b1ad to report latch waits.
>
I am facing windows below compilation error:
1>pgstat.h(726): warning C4005: 'WAIT_TIMEOUT' : macro redefinition
1>c:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\include\wine
Rename WAIT_* constants to PG_WAIT_*.
Windows apparently has a constant named WAIT_TIMEOUT, and some of these
other names are pretty generic, too. Insert "PG_" at the front of each
name in order to disambiguate.
Michael Paquier
Branch
--
master
Details
---
http://git.postgresql.org/pg/
15 matches
Mail list logo