[COMMITTERS] pgsql: Add tests for various connection string issues
Add tests for various connection string issues Add tests for consistent support of connection strings in frontend programs as well as proper handling of unusual characters in database and user names. These tests were developed for the issues of CVE-2016-5424. To allow testing of names with spaces, change the pg_regress command-line options --create-role and --dbname to split their arguments by comma only, not space or comma as before. Only commas were actually used in existing uses. Noah Misch, Michael Paquier, Peter Eisentraut Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8b845520fb0aa50fea7aae44a45cee1b6d87845d Modified Files -- src/bin/pg_dump/t/010_dump_connstr.pl | 142 ++ src/bin/pg_rewind/RewindTest.pm | 2 +- src/bin/scripts/t/010_clusterdb.pl| 5 +- src/bin/scripts/t/090_reindexdb.pl| 9 ++- src/bin/scripts/t/100_vacuumdb.pl | 4 +- src/bin/scripts/t/200_connstr.pl | 38 + src/test/perl/PostgresNode.pm | 29 ++- src/test/perl/TestLib.pm | 14 src/test/regress/pg_regress.c | 35 +++-- 9 files changed, 266 insertions(+), 12 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: Be sure to rewind the tuplestore read pointer in non-leader CTES
Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes. ExecInitCteScan supposed that it didn't have to do anything to the extra tuplestore read pointer it gets from tuplestore_alloc_read_pointer. However, it needs this read pointer to be positioned at the start of the tuplestore, while tuplestore_alloc_read_pointer is actually defined as cloning the current position of read pointer 0. In normal situations that accidentally works because we initialize the whole plan tree at once, before anything gets read. But it fails in an EvalPlanQual recheck, as illustrated in bug #14328 from Dima Pavlov. To fix, just forcibly rewind the pointer after tuplestore_alloc_read_pointer. The cost of doing so is negligible unless the tuplestore is already in TSS_READFILE state, which wouldn't happen in normal cases. We could consider altering tuplestore's API to make that case cheaper, but that would make for a more invasive back-patch and it doesn't seem worth it. This has been broken probably for as long as we've had CTEs, so back-patch to all supported branches. Discussion: <32468.1474548...@sss.pgh.pa.us> Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/0183df5dc000fccf121c1a54504044578e43ec8e Modified Files -- src/backend/executor/nodeCtescan.c | 4 1 file changed, 4 insertions(+) -- 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: Be sure to rewind the tuplestore read pointer in non-leader CTES
Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes. ExecInitCteScan supposed that it didn't have to do anything to the extra tuplestore read pointer it gets from tuplestore_alloc_read_pointer. However, it needs this read pointer to be positioned at the start of the tuplestore, while tuplestore_alloc_read_pointer is actually defined as cloning the current position of read pointer 0. In normal situations that accidentally works because we initialize the whole plan tree at once, before anything gets read. But it fails in an EvalPlanQual recheck, as illustrated in bug #14328 from Dima Pavlov. To fix, just forcibly rewind the pointer after tuplestore_alloc_read_pointer. The cost of doing so is negligible unless the tuplestore is already in TSS_READFILE state, which wouldn't happen in normal cases. We could consider altering tuplestore's API to make that case cheaper, but that would make for a more invasive back-patch and it doesn't seem worth it. This has been broken probably for as long as we've had CTEs, so back-patch to all supported branches. Discussion: <32468.1474548...@sss.pgh.pa.us> Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8552f9b903a099d82763460cb7ca28715d0ad2bb Modified Files -- src/backend/executor/nodeCtescan.c | 4 src/test/isolation/expected/eval-plan-qual.out | 21 + src/test/isolation/specs/eval-plan-qual.spec | 23 +++ 3 files changed, 48 insertions(+) -- 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: Be sure to rewind the tuplestore read pointer in non-leader CTES
Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes. ExecInitCteScan supposed that it didn't have to do anything to the extra tuplestore read pointer it gets from tuplestore_alloc_read_pointer. However, it needs this read pointer to be positioned at the start of the tuplestore, while tuplestore_alloc_read_pointer is actually defined as cloning the current position of read pointer 0. In normal situations that accidentally works because we initialize the whole plan tree at once, before anything gets read. But it fails in an EvalPlanQual recheck, as illustrated in bug #14328 from Dima Pavlov. To fix, just forcibly rewind the pointer after tuplestore_alloc_read_pointer. The cost of doing so is negligible unless the tuplestore is already in TSS_READFILE state, which wouldn't happen in normal cases. We could consider altering tuplestore's API to make that case cheaper, but that would make for a more invasive back-patch and it doesn't seem worth it. This has been broken probably for as long as we've had CTEs, so back-patch to all supported branches. Discussion: <32468.1474548...@sss.pgh.pa.us> Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/73df86a37ba54e35ba8d9e09bc9fe5699b196829 Modified Files -- src/backend/executor/nodeCtescan.c | 4 src/test/isolation/expected/eval-plan-qual.out | 21 + src/test/isolation/specs/eval-plan-qual.spec | 23 +++ 3 files changed, 48 insertions(+) -- 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: Be sure to rewind the tuplestore read pointer in non-leader CTES
Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes. ExecInitCteScan supposed that it didn't have to do anything to the extra tuplestore read pointer it gets from tuplestore_alloc_read_pointer. However, it needs this read pointer to be positioned at the start of the tuplestore, while tuplestore_alloc_read_pointer is actually defined as cloning the current position of read pointer 0. In normal situations that accidentally works because we initialize the whole plan tree at once, before anything gets read. But it fails in an EvalPlanQual recheck, as illustrated in bug #14328 from Dima Pavlov. To fix, just forcibly rewind the pointer after tuplestore_alloc_read_pointer. The cost of doing so is negligible unless the tuplestore is already in TSS_READFILE state, which wouldn't happen in normal cases. We could consider altering tuplestore's API to make that case cheaper, but that would make for a more invasive back-patch and it doesn't seem worth it. This has been broken probably for as long as we've had CTEs, so back-patch to all supported branches. Discussion: <32468.1474548...@sss.pgh.pa.us> Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/c359178350ac7790437feb817c1fb523838abbd9 Modified Files -- src/backend/executor/nodeCtescan.c | 4 src/test/isolation/expected/eval-plan-qual.out | 21 + src/test/isolation/specs/eval-plan-qual.spec | 17 + 3 files changed, 42 insertions(+) -- 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: Be sure to rewind the tuplestore read pointer in non-leader CTES
Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes. ExecInitCteScan supposed that it didn't have to do anything to the extra tuplestore read pointer it gets from tuplestore_alloc_read_pointer. However, it needs this read pointer to be positioned at the start of the tuplestore, while tuplestore_alloc_read_pointer is actually defined as cloning the current position of read pointer 0. In normal situations that accidentally works because we initialize the whole plan tree at once, before anything gets read. But it fails in an EvalPlanQual recheck, as illustrated in bug #14328 from Dima Pavlov. To fix, just forcibly rewind the pointer after tuplestore_alloc_read_pointer. The cost of doing so is negligible unless the tuplestore is already in TSS_READFILE state, which wouldn't happen in normal cases. We could consider altering tuplestore's API to make that case cheaper, but that would make for a more invasive back-patch and it doesn't seem worth it. This has been broken probably for as long as we've had CTEs, so back-patch to all supported branches. Discussion: <32468.1474548...@sss.pgh.pa.us> Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/a88fe25f50ae9ce491fe10a90aeef2cbed6f2b9a Modified Files -- src/backend/executor/nodeCtescan.c | 4 src/test/isolation/expected/eval-plan-qual.out | 21 + src/test/isolation/specs/eval-plan-qual.spec | 17 + 3 files changed, 42 insertions(+) -- 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: Be sure to rewind the tuplestore read pointer in non-leader CTES
Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes. ExecInitCteScan supposed that it didn't have to do anything to the extra tuplestore read pointer it gets from tuplestore_alloc_read_pointer. However, it needs this read pointer to be positioned at the start of the tuplestore, while tuplestore_alloc_read_pointer is actually defined as cloning the current position of read pointer 0. In normal situations that accidentally works because we initialize the whole plan tree at once, before anything gets read. But it fails in an EvalPlanQual recheck, as illustrated in bug #14328 from Dima Pavlov. To fix, just forcibly rewind the pointer after tuplestore_alloc_read_pointer. The cost of doing so is negligible unless the tuplestore is already in TSS_READFILE state, which wouldn't happen in normal cases. We could consider altering tuplestore's API to make that case cheaper, but that would make for a more invasive back-patch and it doesn't seem worth it. This has been broken probably for as long as we've had CTEs, so back-patch to all supported branches. Discussion: <32468.1474548...@sss.pgh.pa.us> Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/96dd77d349424f270d129f8f40e75f762ddcca7d Modified Files -- src/backend/executor/nodeCtescan.c | 4 src/test/isolation/expected/eval-plan-qual.out | 21 + src/test/isolation/specs/eval-plan-qual.spec | 17 + 3 files changed, 42 insertions(+) -- 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: Be sure to rewind the tuplestore read pointer in non-leader CTES
Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes. ExecInitCteScan supposed that it didn't have to do anything to the extra tuplestore read pointer it gets from tuplestore_alloc_read_pointer. However, it needs this read pointer to be positioned at the start of the tuplestore, while tuplestore_alloc_read_pointer is actually defined as cloning the current position of read pointer 0. In normal situations that accidentally works because we initialize the whole plan tree at once, before anything gets read. But it fails in an EvalPlanQual recheck, as illustrated in bug #14328 from Dima Pavlov. To fix, just forcibly rewind the pointer after tuplestore_alloc_read_pointer. The cost of doing so is negligible unless the tuplestore is already in TSS_READFILE state, which wouldn't happen in normal cases. We could consider altering tuplestore's API to make that case cheaper, but that would make for a more invasive back-patch and it doesn't seem worth it. This has been broken probably for as long as we've had CTEs, so back-patch to all supported branches. Discussion: <32468.1474548...@sss.pgh.pa.us> Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/d3dd00e675712da13262149b3478ecbff91525fd Modified Files -- src/backend/executor/nodeCtescan.c | 4 src/test/isolation/expected/eval-plan-qual.out | 21 + src/test/isolation/specs/eval-plan-qual.spec | 23 +++ 3 files changed, 48 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] Re: pgsql: Invent PageIndexTupleOverwrite, and teach BRIN and GiST to use i
Hello! 2016-09-10 3:02 GMT+05:00 Tom Lane : > Invent PageIndexTupleOverwrite, and teach BRIN and GiST to use it. > > Discussion: > > > Details > --- > http://git.postgresql.org/pg/commitdiff/b1328d78f88cdf4f7504004159e530b776f0de16 > > Modified Files > -- > src/backend/access/brin/brin_pageops.c | 6 +- > src/backend/access/brin/brin_xlog.c| 9 +-- > src/backend/access/gist/gist.c | 30 +-- > src/backend/access/gist/gistxlog.c | 29 ++- > src/backend/storage/page/bufpage.c | 142 - > src/include/storage/bufpage.h | 3 +- > 6 files changed, 179 insertions(+), 40 deletions(-) > This commit changes shape of WAL records of GiST and BRIN, but does not bump XLOG_PAGE_MAGIC. Is it for a reason? Best regards, Andrey Borodin. -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Invent PageIndexTupleOverwrite, and teach BRIN and GiST to use i
Andrew Borodin writes: > 2016-09-10 3:02 GMT+05:00 Tom Lane : >> Invent PageIndexTupleOverwrite, and teach BRIN and GiST to use it. > This commit changes shape of WAL records of GiST and BRIN, but does > not bump XLOG_PAGE_MAGIC. Is it for a reason? Yeah, I explained it in part of the commit message you didn't quote: Note that this patch causes a rather subtle WAL incompatibility: the physical page content change represented by certain WAL records is now different than it was before, because while the tuples have the same itempointer line numbers, the tuples themselves are in different places. I have not bumped the WAL version number because I think it doesn't matter unless you are trying to do bitwise comparisons of original and replayed pages, and in any case we're early in a devel cycle and there will probably be more WAL changes before v10 gets out the door. regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] Re: pgsql: Invent PageIndexTupleOverwrite, and teach BRIN and GiST to use i
2016-09-22 23:11 GMT+05:00 Tom Lane : > Yeah, I explained it in part of the commit message you didn't quote: Oh.. sorry, my bad. Focused on code and missed whole thing. > Note that this patch causes a rather subtle WAL incompatibility: the > physical page content change represented by certain WAL records is now > different than it was before, because while the tuples have the same > itempointer line numbers, the tuples themselves are in different places. As for GiST, that was my initial suggestion, but tests of Anastasia Lubennikova showed that in some cases index size is reduced by 3. It's not possible to get 3 times less pages by compatible WAL replay. > I have not bumped the WAL version number because I think it doesn't matter > unless you are trying to do bitwise comparisons of original and replayed > pages, and in any case we're early in a devel cycle and there will > probably > be more WAL changes before v10 gets out the door. I think that's correct assumption. Sorry for time taken. Best regards, Andrey Borodin. -- 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: Remove nearly-unused SizeOfIptrData macro.
Remove nearly-unused SizeOfIptrData macro. Past refactorings have removed all but one reference to SizeOfIptrData (and that one place was in a pretty noncritical spot). Since nobody's complained, it seems probable that there are no supported compilers that don't think sizeof(ItemPointerData) is 6. If there are, we're wasting MAXALIGN per heap tuple anyway, so it's rather silly to worry about whether we can shave space in places like WAL records. Pavan Deolasee Discussion: Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8023b5827fbada6815ce269db4f3373ac77ec7c3 Modified Files -- src/backend/executor/nodeTidscan.c | 2 +- src/include/storage/itemptr.h | 8 ++-- 2 files changed, 3 insertions(+), 7 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: C comment: fix function header comment
C comment: fix function header comment Fix for transformOnConflictClause(). Author: Tomonari Katsumata Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/1ff0042165cf835d1b6a2ab2c3b84c201eb6577b Modified Files -- src/backend/parser/analyze.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 typo in comment.
Fix typo in comment. Daniel Gustafsson Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/674e2de64d66b3a1e261bf07825be54c7cd2f3f6 Modified Files -- src/interfaces/libpq/libpq-int.h | 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
