pgsql: Treat MINGW and MSYS the same in pg_upgrade test script
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_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f6d5a5f6dba515db39047ec07240129090d71538 Modified Files -- src/bin/pg_upgrade/test.sh | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)
pgsql: Treat MINGW and MSYS the same in pg_upgrade test script
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_STABLE Details --- https://git.postgresql.org/pg/commitdiff/01c5ef99cc0c2a193c7446515a40d85fdccc498e Modified Files -- src/bin/pg_upgrade/test.sh | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)
pgsql: Treat MINGW and MSYS the same in pg_upgrade test script
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_STABLE Details --- https://git.postgresql.org/pg/commitdiff/33066b0142893ead9b1bd9709552a9f173ffddb3 Modified Files -- src/bin/pg_upgrade/test.sh | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)
pgsql: Treat MINGW and MSYS the same in pg_upgrade test script
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_STABLE Details --- https://git.postgresql.org/pg/commitdiff/67d5af3f42b72270b0c5a2c36c1f378ab908671a Modified Files -- src/bin/pg_upgrade/test.sh | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)
pgsql: Treat MINGW and MSYS the same in pg_upgrade test script
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 Details --- https://git.postgresql.org/pg/commitdiff/acb96eb7d294a003a9392cdd445630ef137d9918 Modified Files -- src/bin/pg_upgrade/test.sh | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)
pgsql: Treat MINGW and MSYS the same in pg_upgrade test script
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_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3a1417c4265b93d7fdfcdbcb9c9fc18cbbff3b5b Modified Files -- src/bin/pg_upgrade/test.sh | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)
pgsql: Treat MINGW and MSYS the same in pg_upgrade test script
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_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a5364a3df57845af2a2d40938347b555899a0502 Modified Files -- contrib/pg_upgrade/test.sh | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)
pgsql: Adjust to latest Msys2 kernel release number
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 release 10. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b4e7b91011dc2287a700ffe93152aafa9852144b Modified Files -- src/bin/pg_dump/t/010_dump_connstr.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Adjust to latest Msys2 kernel release number
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 release 10. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/97205d04e79ded73ba7fe0196f7817f89a405303 Modified Files -- src/bin/pg_dump/t/010_dump_connstr.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Adjust to latest Msys2 kernel release number
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 release 10. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ad9b419f7cbe82ef843b74a983e7cad656d96ebf Modified Files -- src/bin/pg_dump/t/010_dump_connstr.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Adjust to latest Msys2 kernel release number
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 release 10. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c62b84437f52f0e23924268938916e90b8e5b9e6 Modified Files -- src/bin/pg_dump/t/010_dump_connstr.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: pgsql: Fix error handling of vacuumdb and reindexdb when running out of
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 maximum number of jobs used, causing >> confusing failures when running out of file descriptors when the jobs >> open connections to Postgres. This commit changes the error handling so >> as we do not check anymore for a maximum number of allowed jobs when >> parsing the option value with FD_SETSIZE, but check instead if a file >> descriptor is within the supported range when opening the connections >> for the jobs so as this is detected at the earliest time possible. >> >> Also, improve the error message to give a hint about the number of jobs >> recommended, using a wording given by the reviewers of the patch. > jacana does not like that, and has reported an error for 9.6: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-08-26 > 03%3A51%3A19 > # Running: vacuumdb -zj2 postgres > vacuumdb: vacuuming database "postgres" > vacuumdb: too many jobs for this platform -- try 1 > > I am able to reproduce the problem locally, and the problem is that we > don't declare FD_SETSIZE on Windows before winsock2.h in > scripts_parallel.c (or vacuumdb.c in ~12) so all the Windows machines > running TAP are going to complain on that. > > This matches with the same problem reported here > https://www.postgresql.org/message-id/1248903114.6348.195.camel@lapdragon > > We have never done that before in vacuumdb.c, and because of that I > think that with a high number of jobs we run into buffer overflows. > > The patch attached does the job on my end, any objections? There > is an argument to do that in win32_port.h, but for now I'd rather take > a safe path, or just do for the change in win32_port.h on HEAD. > > (Noticed the missing newline as well in the error string in > back-branches... I'll address it at the same time.) Looks OK. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql: Fix gettext triggers specification
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 -- src/bin/pg_dump/nls.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: pgsql: Fix gettext triggers specification
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
pgsql: Fix gettext triggers specification
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 Files -- src/bin/pg_dump/nls.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Make comment in fmgr.h match the one in fmgr.c.
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 -- master Details --- https://git.postgresql.org/pg/commitdiff/348778ddbc75eddaa7f9c7ce5b6adad8ada564e4 Modified Files -- src/include/fmgr.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Re: pgsql: Fix gettext triggers specification
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 somehow missed pushing that branch. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql: Fix postmaster state machine to handle dead_end child crashes be
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 well. We correctly send SIGQUIT to the startup process, but then: * if the startup process exits with nonzero exit code, as expected, we thought that that indicated a crash and aborted startup. * if the startup process exits with zero exit code, which is possible due to the inherent race condition, we'd advance to PM_RUN state which is fine --- but the code forgot that AbortStartTime would be nonzero in this situation. We'd either die on the Asserts saying that it was zero, or perhaps misbehave later on. (A quick look suggests that the only misbehavior might be busy-waiting due to DetermineSleepTime doing the wrong thing.) To fix the first point, adjust the state-machine logic to recognize that a nonzero exit code is expected after sending SIGQUIT, and have it transition to a state where we can restart the startup process. To fix the second point, change the Asserts to clear the variable rather than just claiming it should be clear already. Perhaps we could improve this further by not treating a crash of a dead_end child as a reason for panic'ing the database. However, since those child processes are connected to shared memory, that seems a bit risky. There are few good reasons for a dead_end child to report failure anyway (the cause of this in Alvaro's report is quite unclear). On balance, therefore, a minimal fix seems best. This is an oversight in commit 45811be94. While that was back-patched, I'm hesitant to back-patch this change. The lack of reasons for a dead_end child to fail suggests that the case should be very rare in the field, which squares with the lack of reports; so it seems like this might not be worth the risk of introducing new issues. In any case we can let it bake awhile in HEAD before considering a back-patch. Discussion: https://postgr.es/m/20190615160950.GA31378@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ee3278239550ff0ec9df72dd798a480c82c2b723 Modified Files -- src/backend/postmaster/postmaster.c | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-)
pgsql: Fix 007_sync_rep.pl to notice failures in ALTER SYSTEM SET.
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 Details --- https://git.postgresql.org/pg/commitdiff/fb57f40eec503d637bf01c298f5cb2472f0d4fdb Modified Files -- src/test/recovery/t/007_sync_rep.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix failure of --jobs with vacuumdb on Windows
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 the default value of FD_SETSIZE, defined at 64. While on it, add a missing newline to the previously-added error message. Per buildfarm member jacana, but this impacts all Windows animals running the TAP tests. I have reproduced the failure locally to check the patch. Author: Michael Paquier Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/20190826054000.ge7...@paquier.xyz Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/128e9b2cc9796da5f5b3056ab8baa4652dd68480 Modified Files -- src/bin/scripts/vacuumdb.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
pgsql: Fix failure of --jobs with reindexdb and vacuumdb on Windows
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 have been using the default value of FD_SETSIZE, defined at 64. Per buildfarm member jacana, but this impacts all Windows animals running the TAP tests. I have reproduced the failure locally to check the patch. Author: Michael Paquier Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/20190826054000.ge7...@paquier.xyz Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9acda731184c1ebdf99172cbb19d0404b7eebc37 Modified Files -- src/bin/scripts/scripts_parallel.c | 4 1 file changed, 4 insertions(+)
pgsql: Fix failure of --jobs with vacuumdb on Windows
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 the default value of FD_SETSIZE, defined at 64. While on it, add a missing newline to the previously-added error message. Per buildfarm member jacana, but this impacts all Windows animals running the TAP tests. I have reproduced the failure locally to check the patch. Author: Michael Paquier Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/20190826054000.ge7...@paquier.xyz Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c90096009347469ce12f389d5e3b8fc5cc319813 Modified Files -- src/bin/scripts/vacuumdb.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
pgsql: Fix failure of --jobs with vacuumdb on Windows
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 the default value of FD_SETSIZE, defined at 64. Per buildfarm member jacana, but this impacts all Windows animals running the TAP tests. I have reproduced the failure locally to check the patch. Author: Michael Paquier Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/20190826054000.ge7...@paquier.xyz Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b783a38d4580d807210e26c2c09eb77b66d7286f Modified Files -- src/bin/scripts/vacuumdb.c | 4 1 file changed, 4 insertions(+)
pgsql: Fix failure of --jobs with vacuumdb on Windows
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 the default value of FD_SETSIZE, defined at 64. While on it, add a missing newline to the previously-added error message. Per buildfarm member jacana, but this impacts all Windows animals running the TAP tests. I have reproduced the failure locally to check the patch. Author: Michael Paquier Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/20190826054000.ge7...@paquier.xyz Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c4d75313ee7ba173d00272fb1f0b7b1aebbb2f58 Modified Files -- src/bin/scripts/vacuumdb.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
pgsql: Fix failure of --jobs with vacuumdb on Windows
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 the default value of FD_SETSIZE, defined at 64. While on it, add a missing newline to the previously-added error message. Per buildfarm member jacana, but this impacts all Windows animals running the TAP tests. I have reproduced the failure locally to check the patch. Author: Michael Paquier Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/20190826054000.ge7...@paquier.xyz Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4ed3bda49d5ed4616bfca80dcb3b409be9720aff Modified Files -- src/bin/scripts/vacuumdb.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-)
Re: pgsql: Fix error handling of vacuumdb and reindexdb when running out of
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
Re: pgsql: Fix error handling of vacuumdb and reindexdb when running out of
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 we are fine. -- Michael signature.asc Description: PGP signature
