[COMMITTERS] pgsql: Test BRIN autosummarization

2017-09-23 Thread Alvaro Herrera
Test BRIN autosummarization There was no coverage for this code. Reported-by: Nikolay Shaplov, Tom Lane Discussion: https://postgr.es/m/2700647.XEouBYNZic@x200m https://postgr.es/m/13849.1506114...@sss.pgh.pa.us Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/c

[COMMITTERS] pgsql: Test BRIN autosummarization

2017-09-23 Thread Alvaro Herrera
Test BRIN autosummarization There was no coverage for this code. Reported-by: Nikolay Shaplov, Tom Lane Discussion: https://postgr.es/m/2700647.XEouBYNZic@x200m https://postgr.es/m/13849.1506114...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdi

[COMMITTERS] pgsql: Fix saving and restoring umask

2017-09-23 Thread Peter Eisentraut
Fix saving and restoring umask In two cases, we set a different umask for some piece of code and restore it afterwards. But if the contained code errors out, the umask is not restored. So add TRY/CATCH blocks to fix that. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/p

[COMMITTERS] pgsql: Fix saving and restoring umask

2017-09-23 Thread Peter Eisentraut
Fix saving and restoring umask In two cases, we set a different umask for some piece of code and restore it afterwards. But if the contained code errors out, the umask is not restored. So add TRY/CATCH blocks to fix that. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/p

[COMMITTERS] pgsql: Fix saving and restoring umask

2017-09-23 Thread Peter Eisentraut
Fix saving and restoring umask In two cases, we set a different umask for some piece of code and restore it afterwards. But if the contained code errors out, the umask is not restored. So add TRY/CATCH blocks to fix that. Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/p

[COMMITTERS] pgsql: Fix saving and restoring umask

2017-09-23 Thread Peter Eisentraut
Fix saving and restoring umask In two cases, we set a different umask for some piece of code and restore it afterwards. But if the contained code errors out, the umask is not restored. So add TRY/CATCH blocks to fix that. Branch -- REL9_2_STABLE Details --- https://git.postgresql.org/p

[COMMITTERS] pgsql: Fix saving and restoring umask

2017-09-23 Thread Peter Eisentraut
Fix saving and restoring umask In two cases, we set a different umask for some piece of code and restore it afterwards. But if the contained code errors out, the umask is not restored. So add TRY/CATCH blocks to fix that. Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/p

[COMMITTERS] pgsql: Fix saving and restoring umask

2017-09-23 Thread Peter Eisentraut
Fix saving and restoring umask In two cases, we set a different umask for some piece of code and restore it afterwards. But if the contained code errors out, the umask is not restored. So add TRY/CATCH blocks to fix that. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/p

Re: [COMMITTERS] pgsql: Fix saving and restoring umask

2017-09-23 Thread Peter Eisentraut
On 9/22/17 17:48, Tom Lane wrote: > Peter Eisentraut writes: >> Fix saving and restoring umask >> In two cases, we set a different umask for some piece of code and >> restore it afterwards. But if the contained code errors out, the umask >> is not restored. So add TRY/CATCH blocks to fix that. >

[COMMITTERS] pgsql: Refactor new file permission handling

2017-09-23 Thread Peter Eisentraut
Refactor new file permission handling The file handling functions from fd.c were called with a diverse mix of notations for the file permissions when they were opening new files. Almost all files created by the server should have the same permissions set. So change the API so that e.g. OpenTransi

[COMMITTERS] pgsql: Ten-second timeout in 013_crash_restart.pl is not enough, let's

2017-09-23 Thread Tom Lane
Ten-second timeout in 013_crash_restart.pl is not enough, let's try 60. Per buildfarm member topminnow. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/01c7d3ef85d4b0e1c52cc1a3542864f95f386f76 Modified Files -- src/test/recovery/t/013_crash_restart.pl |

[COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is

2017-09-23 Thread Tom Lane
Remove pgbench "progress" test pending solution of its timing issues. Buildfarm member skink shows that this is even more flaky than I thought. There are probably some actual pgbench bugs here as well as a timing dependency. But we can't have stuff this unstable in the buildfarm, it obscures oth

[COMMITTERS] pgsql: Improve memory management in autovacuum.c.

2017-09-23 Thread Tom Lane
Improve memory management in autovacuum.c. Invoke vacuum(), as well as "work item" processing, in the PortalContext that do_autovacuum() has manufactured, which will be reset before each such invocation. This ensures cleanup of any memory leaked by these operations. It also avoids the rather dan

Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is

2017-09-23 Thread Fabien COELHO
Hello Tom, Remove pgbench "progress" test pending solution of its timing issues. It would have been nicer to simply comment them out... Buildfarm member skink shows that this is even more flaky than I thought. There are probably some actual pgbench bugs here as well as a timing dependency

Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is

2017-09-23 Thread Andres Freund
Hi, On 2017-09-23 19:57:40 +0200, Fabien COELHO wrote: > According to the trace, the host was so loaded that it could not do anything > for over two seconds, so that the first output is "progress: 2.6", i.e. the > 0 thread did not get any significant time for the first 2.6 seconds... of a > 1 seco

Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is

2017-09-23 Thread Tom Lane
Fabien COELHO writes: > Globally these test failures reveals pathological testing conditions: the > inability to execute a simple select over several seconds. It could have > been OOM or whatever else. Well, I think it's mostly about valgrind making everything really slow. Since we have seen so

[COMMITTERS] pgsql: Fix bogus size calculation in strlist_to_textarray().

2017-09-23 Thread Tom Lane
Fix bogus size calculation in strlist_to_textarray(). It's making an array of Datum, not an array of text *. The mistake is harmless since those are currently the same size, but it's still wrong. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/737639017c87d5a0a466e

[COMMITTERS] pgsql: ... and the very same bug in publicationListToArray().

2017-09-23 Thread Tom Lane
... and the very same bug in publicationListToArray(). Sigh. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/24541ffd788d56009126fff52b2341ada6c84245 Modified Files -- src/backend/commands/subscriptioncmds.c | 8 +--- 1 file changed, 5 insertions(+),

Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is

2017-09-23 Thread Fabien COELHO
If the test must run even when postgres doesn't, it is a little bit hard as a starting assumption for a benchmarking tool:-( I'm unsure what the point of this is. It's not like we discussing removing pgbench, we're talking about an unreliable test. My sentence was probably not very clear.

Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is

2017-09-23 Thread Tom Lane
Fabien COELHO writes: > So this means somehow giving up on coverage, because of one host which can > fail under very unusual testing conditions once in a while. You are attacking a straw man. There is no reason whatever to believe that the problem is confined to one host. We have quite a numbe

[COMMITTERS] pgsql: Fix pg_basebackup test to original intent

2017-09-23 Thread Peter Eisentraut
Fix pg_basebackup test to original intent One test case was meant to check that pg_basebackup does not succeed when a slot is specified with -S but WAL streaming is not selected, which used to require specifying -X stream. Since -X stream is the default in PostgreSQL 10, this test case no longer

[COMMITTERS] pgsql: Fix pg_basebackup test to original intent

2017-09-23 Thread Peter Eisentraut
Fix pg_basebackup test to original intent One test case was meant to check that pg_basebackup does not succeed when a slot is specified with -S but WAL streaming is not selected, which used to require specifying -X stream. Since -X stream is the default in PostgreSQL 10, this test case no longer

[COMMITTERS] pgsql: doc: Expand user documentation on SCRAM

2017-09-23 Thread Peter Eisentraut
doc: Expand user documentation on SCRAM Explain more about how the different password authentication methods and the password_encryption settings relate to each other, give some upgrading advice, and set a better link from the release notes. Reviewed-by: Jeff Janes Branch -- REL_10_STABLE

[COMMITTERS] pgsql: doc: Expand user documentation on SCRAM

2017-09-23 Thread Peter Eisentraut
doc: Expand user documentation on SCRAM Explain more about how the different password authentication methods and the password_encryption settings relate to each other, give some upgrading advice, and set a better link from the release notes. Reviewed-by: Jeff Janes Branch -- master Details

Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is

2017-09-23 Thread Fabien COELHO
You are attacking a straw man. I thought it was tilting at windmills:-) In the TAP-test context, you do have quite a bit of freedom to decide what is a pass and what is a fail. So maybe the path forward is to be more flexible about the pass conditions for this test. Hmmm. I'm not sure tha