pgsql: Attempt to stabilize partition_prune test output (2)

2018-04-13 Thread Alvaro Herrera
Attempt to stabilize partition_prune test output (2) Environmental conditions might cause parallel workers to be scheduled in different ways in this test, destabilizing the EXPLAIN output. Disable use of workers in an attempt to make output stable. Author: David Rowley Diagnosed-by: Thomas Munro

pgsql: Use custom hash opclass for hash partition pruning

2018-04-13 Thread Alvaro Herrera
Use custom hash opclass for hash partition pruning This custom opclass was already in use in other tests -- defined independently in every such file. Move the definition to the earliest test that uses it, and keep it around so that later tests can reuse it. Use it in the tests for pruning of hash

pgsql: In libpq, free any partial query result before collecting a serv

2018-04-13 Thread Tom Lane
In libpq, free any partial query result before collecting a server error. We'd throw away the partial result anyway after parsing the error message. Throwing it away beforehand costs nothing and reduces the risk of out-of-memory failure. Also, at least in systems that behave like glibc/Linux, if

pgsql: In libpq, free any partial query result before collecting a serv

2018-04-13 Thread Tom Lane
In libpq, free any partial query result before collecting a server error. We'd throw away the partial result anyway after parsing the error message. Throwing it away beforehand costs nothing and reduces the risk of out-of-memory failure. Also, at least in systems that behave like glibc/Linux, if

pgsql: In libpq, free any partial query result before collecting a serv

2018-04-13 Thread Tom Lane
In libpq, free any partial query result before collecting a server error. We'd throw away the partial result anyway after parsing the error message. Throwing it away beforehand costs nothing and reduces the risk of out-of-memory failure. Also, at least in systems that behave like glibc/Linux, if

pgsql: In libpq, free any partial query result before collecting a serv

2018-04-13 Thread Tom Lane
In libpq, free any partial query result before collecting a server error. We'd throw away the partial result anyway after parsing the error message. Throwing it away beforehand costs nothing and reduces the risk of out-of-memory failure. Also, at least in systems that behave like glibc/Linux, if

pgsql: In libpq, free any partial query result before collecting a serv

2018-04-13 Thread Tom Lane
In libpq, free any partial query result before collecting a server error. We'd throw away the partial result anyway after parsing the error message. Throwing it away beforehand costs nothing and reduces the risk of out-of-memory failure. Also, at least in systems that behave like glibc/Linux, if

pgsql: In libpq, free any partial query result before collecting a serv

2018-04-13 Thread Tom Lane
In libpq, free any partial query result before collecting a server error. We'd throw away the partial result anyway after parsing the error message. Throwing it away beforehand costs nothing and reduces the risk of out-of-memory failure. Also, at least in systems that behave like glibc/Linux, if

pgsql: Improve regression test coverage for src/backend/tsearch/spell.c

2018-04-13 Thread Tom Lane
Improve regression test coverage for src/backend/tsearch/spell.c. In passing, throw an error if the AF count is too small, rather than just silently discarding extra affix entries. Note that the new regression test cases require installing the updated src/backend/tsearch/dicts files. Arthur Zaki

pgsql: Prevent segfault in expand_tuple with no missing values

2018-04-13 Thread Andrew Dunstan
Prevent segfault in expand_tuple with no missing values Commit 16828d5c forgot to check that it had a set of missing values before trying to retrieve a value from it. An additional query to add coverage for this code is added to the regression test. Per bug report from Andreas Seltenreich. Bran