[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f12681079020eea53ea9a0eb994ac2ee6190770f Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/96f2344f381df94fcb9b84bffc58bbc540edd842 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/7cda702363e8bfb61409bb8cbae13689b19f1648 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/2ef6fe9cbae9fe7789a35cbc5fa1bbf78c163d42 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/499606c806c387ba2f9a9ee773e6b92d99e27221 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix error handling in pltcl_returnnext.
Fix error handling in pltcl_returnnext. We can't throw elog(ERROR) out of a Tcl command procedure; we have to catch the error and return TCL_ERROR to the Tcl interpreter. pltcl_returnnext failed to meet this requirement, so that errors detected by pltcl_build_tuple_result or other functions called here led to longjmp'ing out of the Tcl interpreter and thereby leaving it in a bad state. Use the existing subtransaction support to prevent that. Oversight in commit 26abb50c4, found more or less accidentally by the buildfarm thanks to the tests added in 961bed020. Report: https://postgr.es/m/30647.1483989...@sss.pgh.pa.us Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8c5722948e831c1862a39da2bb5d793a6f2aabab Modified Files -- src/pl/tcl/pltcl.c | 99 -- 1 file changed, 59 insertions(+), 40 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix ALTER TABLE / SET TYPE for irregular inheritance
Fix ALTER TABLE / SET TYPE for irregular inheritance If inherited tables don't have exactly the same schema, the USING clause in an ALTER TABLE / SET DATA TYPE misbehaves when applied to the children tables since commit 9550e8348b79. Starting with that commit, the attribute numbers in the USING expression are fixed during parse analysis. This can lead to bogus errors being reported during execution, such as: ERROR: attribute 2 has wrong type DETAIL: Table has type smallint, but query expects integer. Since it wouldn't do to revert to the original coding, we now apply a transformation to map the attribute numbers to the correct ones for each child. Reported by Justin Pryzby Analysis by Tom Lane; patch by me. Discussion: https://postgr.es/m/20170102225618.ga10...@telsasoft.com Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/4e563a1f6532decf7949324d313f264a4ed38622 Modified Files -- src/backend/access/common/tupconvert.c| 110 ++ src/backend/commands/tablecmds.c | 66 -- src/include/access/tupconvert.h | 4 ++ src/test/regress/expected/alter_table.out | 22 ++ src/test/regress/sql/alter_table.sql | 22 ++ 5 files changed, 175 insertions(+), 49 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix ALTER TABLE / SET TYPE for irregular inheritance
Fix ALTER TABLE / SET TYPE for irregular inheritance If inherited tables don't have exactly the same schema, the USING clause in an ALTER TABLE / SET DATA TYPE misbehaves when applied to the children tables since commit 9550e8348b79. Starting with that commit, the attribute numbers in the USING expression are fixed during parse analysis. This can lead to bogus errors being reported during execution, such as: ERROR: attribute 2 has wrong type DETAIL: Table has type smallint, but query expects integer. Since it wouldn't do to revert to the original coding, we now apply a transformation to map the attribute numbers to the correct ones for each child. Reported by Justin Pryzby Analysis by Tom Lane; patch by me. Discussion: https://postgr.es/m/20170102225618.ga10...@telsasoft.com Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/4d4ab6ccd8a24a91ef9fc1904f0e80a2fd0377fe Modified Files -- src/backend/access/common/tupconvert.c| 110 ++ src/backend/commands/tablecmds.c | 66 -- src/include/access/tupconvert.h | 4 ++ src/test/regress/expected/alter_table.out | 22 ++ src/test/regress/sql/alter_table.sql | 22 ++ 5 files changed, 175 insertions(+), 49 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix ALTER TABLE / SET TYPE for irregular inheritance
Fix ALTER TABLE / SET TYPE for irregular inheritance If inherited tables don't have exactly the same schema, the USING clause in an ALTER TABLE / SET DATA TYPE misbehaves when applied to the children tables since commit 9550e8348b79. Starting with that commit, the attribute numbers in the USING expression are fixed during parse analysis. This can lead to bogus errors being reported during execution, such as: ERROR: attribute 2 has wrong type DETAIL: Table has type smallint, but query expects integer. Since it wouldn't do to revert to the original coding, we now apply a transformation to map the attribute numbers to the correct ones for each child. Reported by Justin Pryzby Analysis by Tom Lane; patch by me. Discussion: https://postgr.es/m/20170102225618.ga10...@telsasoft.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/3957b58b8885441c8d03bc1cfc00e47cf8cd7975 Modified Files -- src/backend/access/common/tupconvert.c| 110 ++ src/backend/commands/tablecmds.c | 66 -- src/include/access/tupconvert.h | 4 ++ src/test/regress/expected/alter_table.out | 22 ++ src/test/regress/sql/alter_table.sql | 22 ++ 5 files changed, 175 insertions(+), 49 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: BRIN revmap pages are not standard pages ...
BRIN revmap pages are not standard pages ... ... and therefore we ought not to tell XLogRegisterBuffer the opposite, when writing XLog for a brin update that moves the index tuple to a different page. Otherwise, xlog insertion would try to "compress the hole" when producing a full-page image for it; but since we don't update pd_lower/upper, the hole covers the whole page. On WAL replay, the revmap page becomes empty and so the entire portion of the index is useless and needs to be recomputed. This is low-probability: a BRIN update only moves an index tuple to a different page when the summary tuple is larger than the existing one, which doesn't happen with fixed-width datatypes. Also, the revmap page must be first after a checkpoint. Report and patch: Kuntal Ghosh Bug is alleged to have detected by a WAL-consistency-checking tool. Discussion: https://postgr.es/m/CAGz5QCJ=00UQjScSEFbV=0qo5shtzb9wwz_fm7+wd83zps9...@mail.gmail.com I posted a test case demonstrating the problem, but I'm refraining from adding it to the test suite; if the WAL consistency tool makes it in, that will be a better way to catch this from regressing. (We should definitely have someting that causes not-same-page updates, though.) Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/4482c6a23f03ba3186d44a41ca77b80a4dee0b38 Modified Files -- src/backend/access/brin/brin_pageops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: BRIN revmap pages are not standard pages ...
BRIN revmap pages are not standard pages ... ... and therefore we ought not to tell XLogRegisterBuffer the opposite, when writing XLog for a brin update that moves the index tuple to a different page. Otherwise, xlog insertion would try to "compress the hole" when producing a full-page image for it; but since we don't update pd_lower/upper, the hole covers the whole page. On WAL replay, the revmap page becomes empty and so the entire portion of the index is useless and needs to be recomputed. This is low-probability: a BRIN update only moves an index tuple to a different page when the summary tuple is larger than the existing one, which doesn't happen with fixed-width datatypes. Also, the revmap page must be first after a checkpoint. Report and patch: Kuntal Ghosh Bug is alleged to have detected by a WAL-consistency-checking tool. Discussion: https://postgr.es/m/CAGz5QCJ=00UQjScSEFbV=0qo5shtzb9wwz_fm7+wd83zps9...@mail.gmail.com I posted a test case demonstrating the problem, but I'm refraining from adding it to the test suite; if the WAL consistency tool makes it in, that will be a better way to catch this from regressing. (We should definitely have someting that causes not-same-page updates, though.) Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/7403561c0f6a8c62b79b6ddf0364ae6c01719068 Modified Files -- src/backend/access/brin/brin_pageops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: BRIN revmap pages are not standard pages ...
BRIN revmap pages are not standard pages ... ... and therefore we ought not to tell XLogRegisterBuffer the opposite, when writing XLog for a brin update that moves the index tuple to a different page. Otherwise, xlog insertion would try to "compress the hole" when producing a full-page image for it; but since we don't update pd_lower/upper, the hole covers the whole page. On WAL replay, the revmap page becomes empty and so the entire portion of the index is useless and needs to be recomputed. This is low-probability: a BRIN update only moves an index tuple to a different page when the summary tuple is larger than the existing one, which doesn't happen with fixed-width datatypes. Also, the revmap page must be first after a checkpoint. Report and patch: Kuntal Ghosh Bug is alleged to have detected by a WAL-consistency-checking tool. Discussion: https://postgr.es/m/CAGz5QCJ=00UQjScSEFbV=0qo5shtzb9wwz_fm7+wd83zps9...@mail.gmail.com I posted a test case demonstrating the problem, but I'm refraining from adding it to the test suite; if the WAL consistency tool makes it in, that will be a better way to catch this from regressing. (We should definitely have someting that causes not-same-page updates, though.) Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/ed8e8b8149220809881d7a275104621fddc36289 Modified Files -- src/backend/access/brin/brin_pageops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Expand the regression tests for PL/Tcl.
Expand the regression tests for PL/Tcl. This raises the test coverage (by line count) in pltcl.c from about 70% to 86%. Karl Lehenbauer and Jim Nasby Discussion: https://postgr.es/m/92a1670d-21b6-8f03-9c13-e4fb2207a...@bluetreble.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/961bed0208912a929a47c5a30190ff76748f3a03 Modified Files -- src/pl/tcl/expected/pltcl_queries.out | 336 -- src/pl/tcl/expected/pltcl_setup.out | 150 +++ src/pl/tcl/sql/pltcl_queries.sql | 112 ++-- src/pl/tcl/sql/pltcl_setup.sql| 145 --- 4 files changed, 654 insertions(+), 89 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use an enum instead of two bools to indicate wal inclusion in ba
Use an enum instead of two bools to indicate wal inclusion in base backups This makes the code easier to read as it becomes more explicit what the different allowed combinations really are. Suggested by Michael Paquier Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/534b6f3ef29a11d19deeef6cef3bc8d4984de3c8 Modified Files -- src/bin/pg_basebackup/pg_basebackup.c | 38 --- 1 file changed, 22 insertions(+), 16 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
