Tweak new jsonb_plperl test cases to work with old Perl versions.
The previous coding here didn't actually produce Inf or NaN double
values in Perl versions 5.8.x. Adopt a suggestion from stackoverflow.
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
Does it help to wait before reattaching?
Revert the map/unmap dance I tried in commit 73042b8d1; that helps
not at all.
Instead, speculate that the unwanted allocation is being done on
another thread, and thus timing variations explain the apparent
unpredictability. Temporarily add a 1-second sl
Andrew Dunstan writes:
> Fingers crossed we'll be OK. Looking at the perl headers on a Windows
> machine I'm doing some other stuff on, the #define is protected by an
> #ifndef. I'm always happy when my hacks can be removed :-)
Well, the early returns on that are promising, but we have another
pr
Map and unmap the shared memory block before risking VirtualFree.
The idea here is to get Windows' userspace infrastructure to allocate
whatever space it needs for MapViewOfFileEx() before we release the
locked-down space that we want to map the shared memory block into.
This is a fairly brute-fo
Further effort at preventing memory map dump from affecting the results.
Rather than elog'ing immediately, push the map data into a preallocated
StringInfo. Perhaps this will prevent some of the mid-operation
allocations that are evidently happening now.
Discussion: https://postgr.es/m/25495.152
On 04/30/2018 02:41 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 4/30/18 13:56, Tom Lane wrote:
>>> So this isn't working on Windows: ...
>>> The reason seems to be this kluge in plperl.h:
>>>
>>> /* stop perl headers from hijacking stdio and other stuff on Windows */
>>> #ifdef WIN32
>>
Peter Eisentraut writes:
> On 4/30/18 13:56, Tom Lane wrote:
>> So this isn't working on Windows: ...
>> The reason seems to be this kluge in plperl.h:
>>
>> /* stop perl headers from hijacking stdio and other stuff on Windows */
>> #ifdef WIN32
>> #define WIN32IO_IS_STDIO
>> /*
>> * isnan is def
On 4/30/18 13:56, Tom Lane wrote:
> So this isn't working on Windows:
>
> contrib/jsonb_plperl/jsonb_plperl.c(226): warning C4013: 'isnan' undefined;
> assuming extern returning int
> [c:\pgbuildfarm\pgbuildroot\HEAD\pgsql.build\jsonb_plperl.vcxproj]
> ...
> .\Release\jsonb_plperl\jsonb_plperl.d
Remove plperl isnan hack
The code previously undefined isnan because of a compiler warning on
MinGW. Since we now need to use isnan, we can't do that anymore.
We might need a different solution if the compiler warning is too
annoying.
Branch
--
master
Details
---
https://git.postgresql
Remove "Generating" output from catalog scripts
So by default, they don't output anything if everything is well.
Discussion:
https://www.postgresql.org/message-id/867f8a1a-6cf0-d835-78d8-0844e4936241%402ndquadrant.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdif
Write error messages about duplicate OIDs to stderr
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c5679256e93d8022b3cdd146a28f6a362a3c79e3
Modified Files
--
src/backend/catalog/genbki.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Peter Eisentraut writes:
> Prevent infinity and NaN in jsonb/plperl transform
So this isn't working on Windows:
contrib/jsonb_plperl/jsonb_plperl.c(226): warning C4013: 'isnan' undefined;
assuming extern returning int
[c:\pgbuildfarm\pgbuildroot\HEAD\pgsql.build\jsonb_plperl.vcxproj]
...
.\Rel
Don't do logical replication of TRUNCATE of zero tables
When due to publication configuration, a TRUNCATE change ends up with
zero tables to be published, don't send the message out, just skip it.
It's not wrong, but obviously useless overhead.
Branch
--
master
Details
---
https://git.po
Prevent infinity and NaN in jsonb/plperl transform
jsonb uses numeric internally, and numeric can store NaN, but that is
not allowed by jsonb on input, so we shouldn't store it. Also prevent
infinity to get a consistent error message. (numeric input would reject
infinity anyway.)
Reported-by: D
Remove Windows module-list-dumping code.
This code is evidently allocating memory and thus confusing matters
even more. Let's see whether we can learn anything with
just VirtualQuery.
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://gi
clean up pg_upgrade tmp_check under MSVC
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/bb779006f4e1881de2c80409225e57e3a3e17d40
Modified Files
--
src/tools/msvc/clean.bat | 1 +
1 file changed, 1 insertion(+)
Ignore file generated during pg_upgrade testing
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0146e32f9f54f8bc556307c4204a404f18c5663b
Modified Files
--
src/bin/pg_upgrade/.gitignore | 1 +
1 file changed, 1 insertion(+)
Dump full memory maps around failing Windows reattach code.
This morning's results from buildfarm member dory make it pretty
clear that something is getting mapped into the just-freed space,
but not what that something is. Replace my minimalistic probes
with a full dump of the process address spa
18 matches
Mail list logo
