pgsql: Attempt to stabilize partition_prune test output (2)
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 Discussion: https://postgr.es/m/CAKJS1f8j24tUX_nOwACiM=uo5jrmrdz8ca0xbg0vhvgfwph...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4d0f6d3f207d977d3685499263993206b56d425a Modified Files -- src/test/regress/expected/partition_prune.out | 79 ++- src/test/regress/sql/partition_prune.sql | 5 ++ 2 files changed, 46 insertions(+), 38 deletions(-)
pgsql: Use custom hash opclass for hash partition pruning
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 partitioning, and since this makes the second expected file unnecessary, put those tests back in partition_prune.sql whence they sprang. Author: Amit Langote Discussion: https://postgr.es/m/CA%2BTgmoZ0D5kJbt8eKXtvVdvTcGGWn6ehWCRSZbWytD-uzH92mQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fafec4cce814b9b15991b62520dc5e5e84655a8a Modified Files -- src/test/regress/expected/alter_table.out | 15 +- src/test/regress/expected/hash_part.out| 23 +-- src/test/regress/expected/insert.out | 32 +++- src/test/regress/expected/partition_prune.out | 191 + src/test/regress/expected/partition_prune_hash.out | 189 .../regress/expected/partition_prune_hash_1.out| 187 src/test/regress/parallel_schedule | 2 +- src/test/regress/serial_schedule | 1 - src/test/regress/sql/alter_table.sql | 15 +- src/test/regress/sql/hash_part.sql | 24 +-- src/test/regress/sql/insert.sql| 36 +++- src/test/regress/sql/partition_prune.sql | 44 - src/test/regress/sql/partition_prune_hash.sql | 41 - 13 files changed, 305 insertions(+), 495 deletions(-)
pgsql: In libpq, free any partial query result before collecting a serv
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 the partial result was very large then the error PGresult would get allocated at high heap addresses, preventing the heap storage used by the partial result from being released to the OS until the error PGresult is freed. In psql >= 9.6, we hold onto the error PGresult until another error is received (for \errverbose), so that this behavior causes a seeming memory leak to persist for awhile, as in a recent complaint from Darafei Praliaskouski. This is a potential performance regression from older versions, justifying back-patching at least that far. But similar behavior may occur in other client applications, so it seems worth just back-patching to all supported branches. Discussion: https://postgr.es/m/CAC8Q8tJ=7cokpepyabje_pf691t8ndfhjp0kzxhvnq_uicf...@mail.gmail.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2278e94ae9410716209487ad929d2eae24da0b47 Modified Files -- src/interfaces/libpq/fe-protocol2.c | 10 +- src/interfaces/libpq/fe-protocol3.c | 10 +- 2 files changed, 18 insertions(+), 2 deletions(-)
pgsql: In libpq, free any partial query result before collecting a serv
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 the partial result was very large then the error PGresult would get allocated at high heap addresses, preventing the heap storage used by the partial result from being released to the OS until the error PGresult is freed. In psql >= 9.6, we hold onto the error PGresult until another error is received (for \errverbose), so that this behavior causes a seeming memory leak to persist for awhile, as in a recent complaint from Darafei Praliaskouski. This is a potential performance regression from older versions, justifying back-patching at least that far. But similar behavior may occur in other client applications, so it seems worth just back-patching to all supported branches. Discussion: https://postgr.es/m/CAC8Q8tJ=7cokpepyabje_pf691t8ndfhjp0kzxhvnq_uicf...@mail.gmail.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/131f6a9583600cc108891ff638e9466d9f17 Modified Files -- src/interfaces/libpq/fe-protocol2.c | 10 +- src/interfaces/libpq/fe-protocol3.c | 10 +- 2 files changed, 18 insertions(+), 2 deletions(-)
pgsql: In libpq, free any partial query result before collecting a serv
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 the partial result was very large then the error PGresult would get allocated at high heap addresses, preventing the heap storage used by the partial result from being released to the OS until the error PGresult is freed. In psql >= 9.6, we hold onto the error PGresult until another error is received (for \errverbose), so that this behavior causes a seeming memory leak to persist for awhile, as in a recent complaint from Darafei Praliaskouski. This is a potential performance regression from older versions, justifying back-patching at least that far. But similar behavior may occur in other client applications, so it seems worth just back-patching to all supported branches. Discussion: https://postgr.es/m/CAC8Q8tJ=7cokpepyabje_pf691t8ndfhjp0kzxhvnq_uicf...@mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d014b38df60fe7f486bfaeb9b55a4851bf32c86f Modified Files -- src/interfaces/libpq/fe-protocol2.c | 10 +- src/interfaces/libpq/fe-protocol3.c | 10 +- 2 files changed, 18 insertions(+), 2 deletions(-)
pgsql: In libpq, free any partial query result before collecting a serv
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 the partial result was very large then the error PGresult would get allocated at high heap addresses, preventing the heap storage used by the partial result from being released to the OS until the error PGresult is freed. In psql >= 9.6, we hold onto the error PGresult until another error is received (for \errverbose), so that this behavior causes a seeming memory leak to persist for awhile, as in a recent complaint from Darafei Praliaskouski. This is a potential performance regression from older versions, justifying back-patching at least that far. But similar behavior may occur in other client applications, so it seems worth just back-patching to all supported branches. Discussion: https://postgr.es/m/CAC8Q8tJ=7cokpepyabje_pf691t8ndfhjp0kzxhvnq_uicf...@mail.gmail.com Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3dd36aa4b36c97cf9e00d29d8b138a1f1990fc62 Modified Files -- src/interfaces/libpq/fe-protocol2.c | 10 +- src/interfaces/libpq/fe-protocol3.c | 10 +- 2 files changed, 18 insertions(+), 2 deletions(-)
pgsql: In libpq, free any partial query result before collecting a serv
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 the partial result was very large then the error PGresult would get allocated at high heap addresses, preventing the heap storage used by the partial result from being released to the OS until the error PGresult is freed. In psql >= 9.6, we hold onto the error PGresult until another error is received (for \errverbose), so that this behavior causes a seeming memory leak to persist for awhile, as in a recent complaint from Darafei Praliaskouski. This is a potential performance regression from older versions, justifying back-patching at least that far. But similar behavior may occur in other client applications, so it seems worth just back-patching to all supported branches. Discussion: https://postgr.es/m/CAC8Q8tJ=7cokpepyabje_pf691t8ndfhjp0kzxhvnq_uicf...@mail.gmail.com Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bbec33c2d0263e367f7ba7d7add768d16861d8a7 Modified Files -- src/interfaces/libpq/fe-protocol2.c | 10 +- src/interfaces/libpq/fe-protocol3.c | 10 +- 2 files changed, 18 insertions(+), 2 deletions(-)
pgsql: In libpq, free any partial query result before collecting a serv
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 the partial result was very large then the error PGresult would get allocated at high heap addresses, preventing the heap storage used by the partial result from being released to the OS until the error PGresult is freed. In psql >= 9.6, we hold onto the error PGresult until another error is received (for \errverbose), so that this behavior causes a seeming memory leak to persist for awhile, as in a recent complaint from Darafei Praliaskouski. This is a potential performance regression from older versions, justifying back-patching at least that far. But similar behavior may occur in other client applications, so it seems worth just back-patching to all supported branches. Discussion: https://postgr.es/m/CAC8Q8tJ=7cokpepyabje_pf691t8ndfhjp0kzxhvnq_uicf...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d25c2ee9c038969eca8080177738dddf97a2cade Modified Files -- src/interfaces/libpq/fe-protocol2.c | 10 +- src/interfaces/libpq/fe-protocol3.c | 10 +- 2 files changed, 18 insertions(+), 2 deletions(-)
pgsql: Improve regression test coverage for src/backend/tsearch/spell.c
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 Zakirov Discussion: https://postgr.es/m/20180413113447.GA32474@zakirov.localdomain Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8bf358c18ec930ddfb998873369e2fc38608d3e1 Modified Files -- .../tsearch/dicts/hunspell_sample_long.affix | 25 +++--- .../tsearch/dicts/hunspell_sample_long.dict| 3 +++ .../tsearch/dicts/hunspell_sample_num.affix| 8 ++ src/backend/tsearch/dicts/hunspell_sample_num.dict | 3 ++- src/backend/tsearch/spell.c| 9 +-- src/test/regress/expected/tsdicts.out | 30 ++ src/test/regress/sql/tsdicts.sql | 5 7 files changed, 77 insertions(+), 6 deletions(-)
pgsql: Prevent segfault in expand_tuple with no missing values
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. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7c44c46deb495a2f3861f402d7f2109263e3d50a Modified Files -- src/backend/access/common/heaptuple.c | 2 +- src/test/regress/expected/fast_default.out | 35 ++ src/test/regress/sql/fast_default.sql | 14 3 files changed, 50 insertions(+), 1 deletion(-)
