Treat MINGW and MSYS the same in pg_upgrade test script
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW
as happens on msys1. Treat these both the same way. This reverts
608a710195a4b in favor of a more general solution.
Backpatch to all live branches.
Branch
--
REL9_6_ST
Treat MINGW and MSYS the same in pg_upgrade test script
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW
as happens on msys1. Treat these both the same way. This reverts
608a710195a4b in favor of a more general solution.
Backpatch to all live branches.
Branch
--
REL_10_ST
Treat MINGW and MSYS the same in pg_upgrade test script
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW
as happens on msys1. Treat these both the same way. This reverts
608a710195a4b in favor of a more general solution.
Backpatch to all live branches.
Branch
--
REL9_5_ST
Treat MINGW and MSYS the same in pg_upgrade test script
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW
as happens on msys1. Treat these both the same way. This reverts
608a710195a4b in favor of a more general solution.
Backpatch to all live branches.
Branch
--
REL_12_ST
Treat MINGW and MSYS the same in pg_upgrade test script
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW
as happens on msys1. Treat these both the same way. This reverts
608a710195a4b in favor of a more general solution.
Backpatch to all live branches.
Branch
--
master
D
Treat MINGW and MSYS the same in pg_upgrade test script
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW
as happens on msys1. Treat these both the same way. This reverts
608a710195a4b in favor of a more general solution.
Backpatch to all live branches.
Branch
--
REL_11_ST
Treat MINGW and MSYS the same in pg_upgrade test script
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW
as happens on msys1. Treat these both the same way. This reverts
608a710195a4b in favor of a more general solution.
Backpatch to all live branches.
Branch
--
REL9_4_ST
Adjust to latest Msys2 kernel release number
Previously 'uname -r' on Msys2 reported a kernele release starting with
2. The latest version starts with 3. In commit 1638623f we specifically
looked for one starting with 2. This is now changed to look for any
digit between 2 and 9.
backpatch to rele
Adjust to latest Msys2 kernel release number
Previously 'uname -r' on Msys2 reported a kernele release starting with
2. The latest version starts with 3. In commit 1638623f we specifically
looked for one starting with 2. This is now changed to look for any
digit between 2 and 9.
backpatch to rele
Adjust to latest Msys2 kernel release number
Previously 'uname -r' on Msys2 reported a kernele release starting with
2. The latest version starts with 3. In commit 1638623f we specifically
looked for one starting with 2. This is now changed to look for any
digit between 2 and 9.
backpatch to rele
Adjust to latest Msys2 kernel release number
Previously 'uname -r' on Msys2 reported a kernele release starting with
2. The latest version starts with 3. In commit 1638623f we specifically
looked for one starting with 2. This is now changed to look for any
digit between 2 and 9.
backpatch to rele
On 8/26/19 1:40 AM, Michael Paquier wrote:
> On Mon, Aug 26, 2019 at 02:17:06AM +, Michael Paquier wrote:
>> Fix error handling of vacuumdb and reindexdb when running out of fds
>>
>> When trying to use a high number of jobs, vacuumdb (and more recently
>> reindexdb) has only checked for a ma
Fix gettext triggers specification
In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of
warn_or_exit_horribly() were changed but this was not updated.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/f2690338814738967d75cc1e35cc1cfac1a40710
Modified Files
-
Peter Eisentraut writes:
> Fix gettext triggers specification
> In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of
> warn_or_exit_horribly() were changed but this was not updated.
Hm, so surely that should be back-patched into v12?
regards, tom lane
Fix gettext triggers specification
In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of
warn_or_exit_horribly() were changed but this was not updated.
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/6bdd9fb003e26201c4ae6293a9f3b239140b6598
Modified
Make comment in fmgr.h match the one in fmgr.c.
Incompletely quoting an API spec does nobody any good. Noted by
Paul Jungwirth. Looks like the discrepancy was my fault originally :-(
Discussion:
https://postgr.es/m/ca+renyu_j8tu_d3kr0pkuogfbpypextendu7a+_d5nofvdv...@mail.gmail.com
Branch
On 2019-08-26 19:32, Tom Lane wrote:
> Peter Eisentraut writes:
>> Fix gettext triggers specification
>> In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of
>> warn_or_exit_horribly() were changed but this was not updated.
>
> Hm, so surely that should be back-patched into v12?
Yup, I
Fix postmaster state machine to handle dead_end child crashes better.
A report from Alvaro Herrera shows that if we're in PM_STARTUP
state, and we spawn a dead_end child to reject some incoming
connection request, and that child dies with an unexpected exit
code, the postmaster does not respond we
Fix 007_sync_rep.pl to notice failures in ALTER SYSTEM SET.
If a test case tried to set an invalid value of synchronous_standby_names,
the test script didn't detect that, which seems like a bad idea.
Noticed while testing a proposed patch that broke some of these
test cases.
Branch
--
master
Fix failure of --jobs with vacuumdb on Windows
FD_SETSIZE needs to be declared before winsock2.h, or it is possible to
run into buffer overflow issues when using --jobs. This is similar to
pgbench's solution done in a23c641.
This has been introduced by 71d84ef, and older versions have been using
Fix failure of --jobs with reindexdb and vacuumdb on Windows
FD_SETSIZE needs to be declared before winsock2.h, or it is possible to
run into buffer overflow issues when using --jobs. This is similar to
pgbench's solution done in a23c641.
This has been introduced by 71d84ef, and older versions h
Fix failure of --jobs with vacuumdb on Windows
FD_SETSIZE needs to be declared before winsock2.h, or it is possible to
run into buffer overflow issues when using --jobs. This is similar to
pgbench's solution done in a23c641.
This has been introduced by 71d84ef, and older versions have been using
Fix failure of --jobs with vacuumdb on Windows
FD_SETSIZE needs to be declared before winsock2.h, or it is possible to
run into buffer overflow issues when using --jobs. This is similar to
pgbench's solution done in a23c641.
This has been introduced by 71d84ef, and older versions have been using
Fix failure of --jobs with vacuumdb on Windows
FD_SETSIZE needs to be declared before winsock2.h, or it is possible to
run into buffer overflow issues when using --jobs. This is similar to
pgbench's solution done in a23c641.
This has been introduced by 71d84ef, and older versions have been using
Fix failure of --jobs with vacuumdb on Windows
FD_SETSIZE needs to be declared before winsock2.h, or it is possible to
run into buffer overflow issues when using --jobs. This is similar to
pgbench's solution done in a23c641.
This has been introduced by 71d84ef, and older versions have been using
On Mon, Aug 26, 2019 at 11:36:50AM -0400, Andrew Dunstan wrote:
> Looks OK.
Thanks Andrew for looking at the patch. I have now committed it on
all the impacted branches, after running vcregress bincheck for all of
them with MSVC.
--
Michael
signature.asc
Description: PGP signature
On Tue, Aug 27, 2019 at 09:18:27AM +0900, Michael Paquier wrote:
> Thanks Andrew for looking at the patch. I have now committed it on
> all the impacted branches, after running vcregress bincheck for all of
> them with MSVC.
bowerbird has turned back to green on 9.5 and 9.6 now, so it seems
that
27 matches
Mail list logo
