[COMMITTERS] pgsql: Tighten test in contrib/bloom/t/001_wal.pl.
Tighten test in contrib/bloom/t/001_wal.pl. Make bloom WAL test compare psql output text, not just result codes; this was evidently the intent all along, but it was mis-coded. In passing, make sure we will notice any failure in setup steps. Alexander Korotkov, reviewed by Michael Paquier and Masahiko Sawada Discussion: https://postgr.es/m/capphfdtohpdq9rc5mdwjxq+3vsbnw534kv_5o65dtqrsdvj...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7e60e678615b1f803ac73faee71cca79ec310d1d Modified Files -- contrib/bloom/t/001_wal.pl | 18 +- 1 file changed, 9 insertions(+), 9 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: Tighten test in contrib/bloom/t/001_wal.pl.
Tighten test in contrib/bloom/t/001_wal.pl. Make bloom WAL test compare psql output text, not just result codes; this was evidently the intent all along, but it was mis-coded. In passing, make sure we will notice any failure in setup steps. Alexander Korotkov, reviewed by Michael Paquier and Masahiko Sawada Discussion: https://postgr.es/m/capphfdtohpdq9rc5mdwjxq+3vsbnw534kv_5o65dtqrsdvj...@mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d33fc27e8df65e89497b4b50e82900fc2bfd0b14 Modified Files -- contrib/bloom/t/001_wal.pl | 18 +- 1 file changed, 9 insertions(+), 9 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: Tighten test in contrib/bloom/t/001_wal.pl.
Tighten test in contrib/bloom/t/001_wal.pl. Make bloom WAL test compare psql output text, not just result codes; this was evidently the intent all along, but it was mis-coded. In passing, make sure we will notice any failure in setup steps. Alexander Korotkov, reviewed by Michael Paquier and Masahiko Sawada Discussion: https://postgr.es/m/capphfdtohpdq9rc5mdwjxq+3vsbnw534kv_5o65dtqrsdvj...@mail.gmail.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/859662c26cf9eac8bfa50a83913523606bdf3e28 Modified Files -- contrib/bloom/t/001_wal.pl | 18 +- 1 file changed, 9 insertions(+), 9 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: Refactor permissions checks for large objects.
Refactor permissions checks for large objects. Up to now, ACL checks for large objects happened at the level of the SQL-callable functions, which led to CVE-2017-7548 because of a missing check. Push them down to be enforced in inv_api.c as much as possible, in hopes of preventing future bugs. This does have the effect of moving read and write permission errors to happen at lo_open time not loread or lowrite time, but that seems acceptable. Michael Paquier and Tom Lane Discussion: https://postgr.es/m/cab7npqrhmnoybetnc_2ejsuzsm00z+bwkv9sy6tnvsd5gwt...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ae20b23a9e7029f31ee902da08a464d968319f56 Modified Files -- src/backend/catalog/objectaddress.c| 2 +- src/backend/libpq/be-fsstubs.c | 88 +-- src/backend/storage/large_object/inv_api.c | 108 +++-- src/backend/utils/misc/guc.c | 12 ++-- src/include/libpq/be-fsstubs.h | 5 -- src/include/storage/large_object.h | 13 ++-- 6 files changed, 117 insertions(+), 111 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: Restrict lo_import()/lo_export() via SQL permissions not hard-wi
Restrict lo_import()/lo_export() via SQL permissions not hard-wired checks. While it's generally unwise to give permissions on these functions to anyone but a superuser, we've been moving away from hard-wired permission checks inside functions in favor of using the SQL permission system to control access. Bring lo_import() and lo_export() into compliance with that approach. In particular, this removes the manual configuration option ALLOW_DANGEROUS_LO_FUNCTIONS. That dates back to 1999 (commit 4cd4a54c8); it's unlikely anyone has used it in many years. Moreover, if you really want such behavior, now you can get it with GRANT ... TO PUBLIC instead. Michael Paquier Discussion: https://postgr.es/m/cab7npqrhmnoybetnc_2ejsuzsm00z+bwkv9sy6tnvsd5gwt...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5ecc0d738e5864848bbc2d1d97e56d5846624ba2 Modified Files -- src/backend/catalog/system_views.sql | 10 ++ src/backend/libpq/be-fsstubs.c | 16 src/include/catalog/catversion.h | 2 +- src/include/pg_config_manual.h | 10 -- src/test/regress/expected/privileges.out | 10 ++ src/test/regress/sql/privileges.sql | 2 ++ 6 files changed, 19 insertions(+), 31 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 typo in ALTER SYSTEM output.
Fix typo in ALTER SYSTEM output. The header comment written into postgresql.auto.conf by ALTER SYSTEM should match what initdb put there originally. Feike Steenbergen Discussion: https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1da48a9a6b9dced66610b70f94f1e5418afc1f8c Modified Files -- src/backend/utils/misc/guc.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 ALTER SYSTEM output.
Fix typo in ALTER SYSTEM output. The header comment written into postgresql.auto.conf by ALTER SYSTEM should match what initdb put there originally. Feike Steenbergen Discussion: https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4384f8a51b8b0a2eaac3f2f9d25825cd5f5f4b7a Modified Files -- src/backend/utils/misc/guc.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 ALTER SYSTEM output.
Fix typo in ALTER SYSTEM output. The header comment written into postgresql.auto.conf by ALTER SYSTEM should match what initdb put there originally. Feike Steenbergen Discussion: https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6c3a7ba5bb0f960ed412b1c36e815f53347b3d79 Modified Files -- src/backend/utils/misc/guc.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 ALTER SYSTEM output.
Fix typo in ALTER SYSTEM output. The header comment written into postgresql.auto.conf by ALTER SYSTEM should match what initdb put there originally. Feike Steenbergen Discussion: https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b2ad6f9e2614f80e6dd88fe584e3aefac52cc454 Modified Files -- src/backend/utils/misc/guc.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 ALTER SYSTEM output.
Fix typo in ALTER SYSTEM output. The header comment written into postgresql.auto.conf by ALTER SYSTEM should match what initdb put there originally. Feike Steenbergen Discussion: https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3c966ce65317e8c72f4368b98dd19e753a9eae73 Modified Files -- src/backend/utils/misc/guc.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 bogus logic for checking executables' versions within pg_upg
Fix bogus logic for checking executables' versions within pg_upgrade. Somebody messed up a refactoring here. As it stood, we'd check pg_ctl's --version output twice for each cluster. Worse, the first check for the new cluster's version happened before we'd done any validate_exec checks there, breaking the check ordering the code intended. A. Akenteva Discussion: https://postgr.es/m/f9266a85d918a3cf3a386b5148aee...@postgrespro.ru Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/115a7075633899408fc1ab85f3bc2e5deeaa5e45 Modified Files -- src/bin/pg_upgrade/exec.c | 9 - 1 file changed, 4 insertions(+), 5 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 bogus logic for checking executables' versions within pg_upg
Fix bogus logic for checking executables' versions within pg_upgrade. Somebody messed up a refactoring here. As it stood, we'd check pg_ctl's --version output twice for each cluster. Worse, the first check for the new cluster's version happened before we'd done any validate_exec checks there, breaking the check ordering the code intended. A. Akenteva Discussion: https://postgr.es/m/f9266a85d918a3cf3a386b5148aee...@postgrespro.ru Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9be95ef156e7c2ae0924300acddd483504fa33b3 Modified Files -- src/bin/pg_upgrade/exec.c | 9 - 1 file changed, 4 insertions(+), 5 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: Revert "Allow --with-bonjour to work with non-macOS implementati
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour." Upon further review, our Bonjour code doesn't actually work with the Avahi not-too-compatible compatibility library. While you can get it to work on non-macOS platforms if you link to Apple's own mDNSResponder code, there don't seem to be many people who care about that. Leaving in the AC_SEARCH_LIBS call seems more likely to encourage people to build broken configurations than to do anything very useful. Hence, remove the AC_SEARCH_LIBS call and put in a warning comment instead. Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9aa6a1b29b0238802583a3b358142752a77c253d Modified Files -- configure| 58 -- configure.in | 8 ++-- 2 files changed, 6 insertions(+), 60 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: Revert "Allow --with-bonjour to work with non-macOS implementati
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour." Upon further review, our Bonjour code doesn't actually work with the Avahi not-too-compatible compatibility library. While you can get it to work on non-macOS platforms if you link to Apple's own mDNSResponder code, there don't seem to be many people who care about that. Leaving in the AC_SEARCH_LIBS call seems more likely to encourage people to build broken configurations than to do anything very useful. Hence, remove the AC_SEARCH_LIBS call and put in a warning comment instead. Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/28d177e3f95e3aef72f53e9e55096b350d1d5d9b Modified Files -- configure| 58 -- configure.in | 8 ++-- 2 files changed, 6 insertions(+), 60 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: Revert "Allow --with-bonjour to work with non-macOS implementati
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour." Upon further review, our Bonjour code doesn't actually work with the Avahi not-too-compatible compatibility library. While you can get it to work on non-macOS platforms if you link to Apple's own mDNSResponder code, there don't seem to be many people who care about that. Leaving in the AC_SEARCH_LIBS call seems more likely to encourage people to build broken configurations than to do anything very useful. Hence, remove the AC_SEARCH_LIBS call and put in a warning comment instead. Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/20d9adab60754ac71b0b500c91c45e12e940b3ce Modified Files -- configure| 58 -- configure.in | 8 ++-- 2 files changed, 6 insertions(+), 60 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: Revert "Allow --with-bonjour to work with non-macOS implementati
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour." Upon further review, our Bonjour code doesn't actually work with the Avahi not-too-compatible compatibility library. While you can get it to work on non-macOS platforms if you link to Apple's own mDNSResponder code, there don't seem to be many people who care about that. Leaving in the AC_SEARCH_LIBS call seems more likely to encourage people to build broken configurations than to do anything very useful. Hence, remove the AC_SEARCH_LIBS call and put in a warning comment instead. Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1772c5c6eee7f3eeaa0e485f67e9cd92f165e1cc Modified Files -- configure| 58 -- configure.in | 8 ++-- 2 files changed, 6 insertions(+), 60 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: Revert "Allow --with-bonjour to work with non-macOS implementati
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour." Upon further review, our Bonjour code doesn't actually work with the Avahi not-too-compatible compatibility library. While you can get it to work on non-macOS platforms if you link to Apple's own mDNSResponder code, there don't seem to be many people who care about that. Leaving in the AC_SEARCH_LIBS call seems more likely to encourage people to build broken configurations than to do anything very useful. Hence, remove the AC_SEARCH_LIBS call and put in a warning comment instead. Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3b04eb98f5f330215b67e7818ef136d991f9a16e Modified Files -- configure| 58 -- configure.in | 8 ++-- 2 files changed, 6 insertions(+), 60 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: Revert "Allow --with-bonjour to work with non-macOS implementati
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour." Upon further review, our Bonjour code doesn't actually work with the Avahi not-too-compatible compatibility library. While you can get it to work on non-macOS platforms if you link to Apple's own mDNSResponder code, there don't seem to be many people who care about that. Leaving in the AC_SEARCH_LIBS call seems more likely to encourage people to build broken configurations than to do anything very useful. Hence, remove the AC_SEARCH_LIBS call and put in a warning comment instead. Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/89df643c3b3350de1b0e0d5cddd2f439972ca00f Modified Files -- configure| 91 configure.in | 8 -- 2 files changed, 6 insertions(+), 93 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: Make json{b}_populate_recordset() use the right tuple descriptor
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclosure of server memory contents seems possible as well, for a
skilled attacker capable of issuing crafted SQL commands. Instead, use
the query-supplied descriptor only when there is no input tuple to look at,
and otherwise get a tuple descriptor based on the input tuple's own type
marking. The core code will detect any type mismatch in the latter case.
Michael Paquier and Tom Lane, per a report from David Rowley.
Back-patch to 9.3 where this functionality was introduced.
Security: CVE-2017-15098
Branch
--
REL9_3_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/c0c8807ded2f59c25b375998ef24ff09994563a1
Modified Files
--
src/backend/utils/adt/jsonfuncs.c | 58 --
src/test/regress/expected/json.out | 13 +
src/test/regress/sql/json.sql | 5
3 files changed, 55 insertions(+), 21 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: Make json{b}_populate_recordset() use the right tuple descriptor
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclosure of server memory contents seems possible as well, for a
skilled attacker capable of issuing crafted SQL commands. Instead, use
the query-supplied descriptor only when there is no input tuple to look at,
and otherwise get a tuple descriptor based on the input tuple's own type
marking. The core code will detect any type mismatch in the latter case.
Michael Paquier and Tom Lane, per a report from David Rowley.
Back-patch to 9.3 where this functionality was introduced.
Security: CVE-2017-15098
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/d5fe5fb232a4e57c66779b8b6acdcb458e9b8b9c
Modified Files
--
src/backend/utils/adt/jsonfuncs.c | 36 +---
src/test/regress/expected/json.out | 13 +
src/test/regress/expected/jsonb.out | 13 +
src/test/regress/sql/json.sql | 6 ++
src/test/regress/sql/jsonb.sql | 6 ++
5 files changed, 63 insertions(+), 11 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: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099 Branch -- REL9_2_STABLE Details --- https://git.postgresql.org/pg/commitdiff/203b965f275061894621a5a359213ac77558d33f Modified Files -- doc/src/sgml/release-9.2.sgml | 25 + 1 file changed, 25 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: Make json{b}_populate_recordset() use the right tuple descriptor
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclosure of server memory contents seems possible as well, for a
skilled attacker capable of issuing crafted SQL commands. Instead, use
the query-supplied descriptor only when there is no input tuple to look at,
and otherwise get a tuple descriptor based on the input tuple's own type
marking. The core code will detect any type mismatch in the latter case.
Michael Paquier and Tom Lane, per a report from David Rowley.
Back-patch to 9.3 where this functionality was introduced.
Security: CVE-2017-15098
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/c30f082d2767c22cefb8875dcb1932e5ed338db6
Modified Files
--
src/backend/utils/adt/jsonfuncs.c | 39 ++---
src/test/regress/expected/json.out | 13 +
src/test/regress/expected/jsonb.out | 13 +
src/test/regress/sql/json.sql | 6 ++
src/test/regress/sql/jsonb.sql | 6 ++
5 files changed, 66 insertions(+), 11 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: Make json{b}_populate_recordset() use the right tuple descriptor
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclosure of server memory contents seems possible as well, for a
skilled attacker capable of issuing crafted SQL commands. Instead, use
the query-supplied descriptor only when there is no input tuple to look at,
and otherwise get a tuple descriptor based on the input tuple's own type
marking. The core code will detect any type mismatch in the latter case.
Michael Paquier and Tom Lane, per a report from David Rowley.
Back-patch to 9.3 where this functionality was introduced.
Security: CVE-2017-15098
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/38e825632be777a6ea4a39796e121c39728403b3
Modified Files
--
src/backend/utils/adt/jsonfuncs.c | 36 +---
src/test/regress/expected/json.out | 13 +
src/test/regress/expected/jsonb.out | 13 +
src/test/regress/sql/json.sql | 6 ++
src/test/regress/sql/jsonb.sql | 6 ++
5 files changed, 63 insertions(+), 11 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: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fb3930ab1fdb53ad842307a47ddaa1fed4e85d5c Modified Files -- doc/src/sgml/release-9.2.sgml | 25 + doc/src/sgml/release-9.3.sgml | 42 ++ 2 files changed, 67 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: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e7bae63e02dee20fdcbad2664d4722c80febf8a1 Modified Files -- doc/src/sgml/release-9.2.sgml | 25 + doc/src/sgml/release-9.3.sgml | 42 ++ doc/src/sgml/release-9.4.sgml | 42 ++ 3 files changed, 109 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: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7b4c179b70a59ad2dbd5c928ce8fc84629da0237 Modified Files -- doc/src/sgml/release-9.2.sgml | 25 +++ doc/src/sgml/release-9.3.sgml | 42 doc/src/sgml/release-9.4.sgml | 42 doc/src/sgml/release-9.5.sgml | 75 ++- 4 files changed, 183 insertions(+), 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: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/50abeafc74a812d2449ec49dc16e99baf8c5023a Modified Files -- doc/src/sgml/release-10.sgml | 108 +- doc/src/sgml/release-9.2.sgml | 25 ++ doc/src/sgml/release-9.3.sgml | 42 doc/src/sgml/release-9.4.sgml | 42 doc/src/sgml/release-9.5.sgml | 75 - doc/src/sgml/release-9.6.sgml | 75 - 6 files changed, 364 insertions(+), 3 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: Add tests for json{b}_populate_recordset() crash case.
Add tests for json{b}_populate_recordset() crash case.
The problem reported as CVE-2017-15098 was already resolved in HEAD by
commit 37a795a60, but let's add the relevant test cases anyway.
Michael Paquier and Tom Lane, per a report from David Rowley.
Security: CVE-2017-15098
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/b574228715f0fd77ed1f4f084603cff9e757e992
Modified Files
--
src/test/regress/expected/json.out | 13 +
src/test/regress/expected/jsonb.out | 13 +
src/test/regress/sql/json.sql | 6 ++
src/test/regress/sql/jsonb.sql | 6 ++
4 files changed, 38 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: Make json{b}_populate_recordset() use the right tuple descriptor
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclosure of server memory contents seems possible as well, for a
skilled attacker capable of issuing crafted SQL commands. Instead, use
the query-supplied descriptor only when there is no input tuple to look at,
and otherwise get a tuple descriptor based on the input tuple's own type
marking. The core code will detect any type mismatch in the latter case.
Michael Paquier and Tom Lane, per a report from David Rowley.
Back-patch to 9.3 where this functionality was introduced.
Security: CVE-2017-15098
Branch
--
REL9_4_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/70846ee0597b4aabc11ffe252eb972de6f77a021
Modified Files
--
src/backend/utils/adt/jsonfuncs.c | 36 +---
src/test/regress/expected/json.out | 13 +
src/test/regress/expected/jsonb.out | 13 +
src/test/regress/sql/json.sql | 6 ++
src/test/regress/sql/jsonb.sql | 6 ++
5 files changed, 63 insertions(+), 11 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: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d69c0710a68068c7a415aaefd2c7d51f3197fe38 Modified Files -- doc/src/sgml/release-9.2.sgml | 25 +++ doc/src/sgml/release-9.3.sgml | 42 doc/src/sgml/release-9.4.sgml | 42 doc/src/sgml/release-9.5.sgml | 75 ++- doc/src/sgml/release-9.6.sgml | 75 ++- 5 files changed, 257 insertions(+), 2 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: Allow --with-bonjour to work with non-macOS implementations of B
Allow --with-bonjour to work with non-macOS implementations of Bonjour. On macOS the relevant functions require no special library, but elsewhere we need to pull in libdns_sd. Back-patch to supported branches. No docs change since the docs do not suggest that this is a Mac-only feature. Luke Lonergan Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/08d440b5cb223f76723a955594b7b8fa555edfe3 Modified Files -- configure| 58 ++ configure.in | 6 -- 2 files changed, 62 insertions(+), 2 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: Allow --with-bonjour to work with non-macOS implementations of B
Allow --with-bonjour to work with non-macOS implementations of Bonjour. On macOS the relevant functions require no special library, but elsewhere we need to pull in libdns_sd. Back-patch to supported branches. No docs change since the docs do not suggest that this is a Mac-only feature. Luke Lonergan Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f57b070943e839a08a3676ae0b09b27dcbdec8a9 Modified Files -- configure| 58 ++ configure.in | 6 -- 2 files changed, 62 insertions(+), 2 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: Allow --with-bonjour to work with non-macOS implementations of B
Allow --with-bonjour to work with non-macOS implementations of Bonjour. On macOS the relevant functions require no special library, but elsewhere we need to pull in libdns_sd. Back-patch to supported branches. No docs change since the docs do not suggest that this is a Mac-only feature. Luke Lonergan Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9b9cb3c4534d717c1c95758670198ebbf8a20af2 Modified Files -- configure| 58 ++ configure.in | 6 -- 2 files changed, 62 insertions(+), 2 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: Allow --with-bonjour to work with non-macOS implementations of B
Allow --with-bonjour to work with non-macOS implementations of Bonjour. On macOS the relevant functions require no special library, but elsewhere we need to pull in libdns_sd. Back-patch to supported branches. No docs change since the docs do not suggest that this is a Mac-only feature. Luke Lonergan Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9042e927eafb2b3f1d5d0c02d9640d357a5a12a7 Modified Files -- configure| 91 configure.in | 6 ++-- 2 files changed, 95 insertions(+), 2 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: Allow --with-bonjour to work with non-macOS implementations of B
Allow --with-bonjour to work with non-macOS implementations of Bonjour. On macOS the relevant functions require no special library, but elsewhere we need to pull in libdns_sd. Back-patch to supported branches. No docs change since the docs do not suggest that this is a Mac-only feature. Luke Lonergan Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/58bc9ea033f7361e4787dc6d29a9ff0b246c8fe4 Modified Files -- configure| 58 ++ configure.in | 6 -- 2 files changed, 62 insertions(+), 2 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: Allow --with-bonjour to work with non-macOS implementations of B
Allow --with-bonjour to work with non-macOS implementations of Bonjour. On macOS the relevant functions require no special library, but elsewhere we need to pull in libdns_sd. Back-patch to supported branches. No docs change since the docs do not suggest that this is a Mac-only feature. Luke Lonergan Discussion: https://postgr.es/m/2d8331c5-d64f-44c1-8717-63edc6eaf...@brightforge.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0e9294a689726b9e35545a3e29292d53c80c798c Modified Files -- configure| 58 ++ configure.in | 6 -- 2 files changed, 62 insertions(+), 2 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: Doc: fix erroneous example.
Doc: fix erroneous example. The grammar requires these options to appear the other way 'round. jo...@posteo.de Discussion: https://postgr.es/m/78933bd0-45ce-690e-b832-a328dd1a5...@posteo.de Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6c05b8150327ca5f58e47ebe4f2dfa235ef930e5 Modified Files -- doc/src/sgml/ddl.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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: Doc: fix erroneous example.
Doc: fix erroneous example. The grammar requires these options to appear the other way 'round. jo...@posteo.de Discussion: https://postgr.es/m/78933bd0-45ce-690e-b832-a328dd1a5...@posteo.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bd65e0c62486e6108a7dc824f918754a13072f7a Modified Files -- doc/src/sgml/ddl.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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 two violations of the ResourceOwnerEnlarge/Remember protocol
Fix two violations of the ResourceOwnerEnlarge/Remember protocol. The point of having separate ResourceOwnerEnlargeFoo and ResourceOwnerRememberFoo functions is so that resource allocation can happen in between. Doing it in some other order is just wrong. OpenTemporaryFile() did open(), enlarge, remember, which would leak the open file if the enlarge step ran out of memory. Because fd.c has its own layer of resource-remembering, the consequences look like they'd be limited to an intratransaction FD leak, but it's still not good. IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow up if the incr-refcount step ever failed. It was safe enough when written, but since the introduction of PrivateRefCountHash, I think the assumption that no error could happen there is pretty shaky. The odds of real problems from either bug are probably small, but still, back-patch to supported branches. Thomas Munro and Tom Lane, per a comment from Andres Freund Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/13492fcf9bb1a25034db3e5ec200a999b1efc371 Modified Files -- src/backend/storage/buffer/bufmgr.c | 2 +- src/backend/storage/file/fd.c | 10 -- 2 files changed, 9 insertions(+), 3 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 two violations of the ResourceOwnerEnlarge/Remember protocol
Fix two violations of the ResourceOwnerEnlarge/Remember protocol. The point of having separate ResourceOwnerEnlargeFoo and ResourceOwnerRememberFoo functions is so that resource allocation can happen in between. Doing it in some other order is just wrong. OpenTemporaryFile() did open(), enlarge, remember, which would leak the open file if the enlarge step ran out of memory. Because fd.c has its own layer of resource-remembering, the consequences look like they'd be limited to an intratransaction FD leak, but it's still not good. IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow up if the incr-refcount step ever failed. It was safe enough when written, but since the introduction of PrivateRefCountHash, I think the assumption that no error could happen there is pretty shaky. The odds of real problems from either bug are probably small, but still, back-patch to supported branches. Thomas Munro and Tom Lane, per a comment from Andres Freund Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c5269472ea9bb4a6fbb8a0510f7d676d725933ab Modified Files -- src/backend/storage/buffer/bufmgr.c | 2 +- src/backend/storage/file/fd.c | 10 -- 2 files changed, 9 insertions(+), 3 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 two violations of the ResourceOwnerEnlarge/Remember protocol
Fix two violations of the ResourceOwnerEnlarge/Remember protocol. The point of having separate ResourceOwnerEnlargeFoo and ResourceOwnerRememberFoo functions is so that resource allocation can happen in between. Doing it in some other order is just wrong. OpenTemporaryFile() did open(), enlarge, remember, which would leak the open file if the enlarge step ran out of memory. Because fd.c has its own layer of resource-remembering, the consequences look like they'd be limited to an intratransaction FD leak, but it's still not good. IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow up if the incr-refcount step ever failed. It was safe enough when written, but since the introduction of PrivateRefCountHash, I think the assumption that no error could happen there is pretty shaky. The odds of real problems from either bug are probably small, but still, back-patch to supported branches. Thomas Munro and Tom Lane, per a comment from Andres Freund Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b89ad383da7dfcf1c5888076d60bb914c6169ec6 Modified Files -- src/backend/storage/buffer/bufmgr.c | 2 +- src/backend/storage/file/fd.c | 10 -- 2 files changed, 9 insertions(+), 3 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 two violations of the ResourceOwnerEnlarge/Remember protocol
Fix two violations of the ResourceOwnerEnlarge/Remember protocol. The point of having separate ResourceOwnerEnlargeFoo and ResourceOwnerRememberFoo functions is so that resource allocation can happen in between. Doing it in some other order is just wrong. OpenTemporaryFile() did open(), enlarge, remember, which would leak the open file if the enlarge step ran out of memory. Because fd.c has its own layer of resource-remembering, the consequences look like they'd be limited to an intratransaction FD leak, but it's still not good. IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow up if the incr-refcount step ever failed. It was safe enough when written, but since the introduction of PrivateRefCountHash, I think the assumption that no error could happen there is pretty shaky. The odds of real problems from either bug are probably small, but still, back-patch to supported branches. Thomas Munro and Tom Lane, per a comment from Andres Freund Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/442bc4160caee01579f5c112c23d9bb5f121f6b6 Modified Files -- src/backend/storage/buffer/bufmgr.c | 2 +- src/backend/storage/file/fd.c | 10 -- 2 files changed, 9 insertions(+), 3 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 two violations of the ResourceOwnerEnlarge/Remember protocol
Fix two violations of the ResourceOwnerEnlarge/Remember protocol. The point of having separate ResourceOwnerEnlargeFoo and ResourceOwnerRememberFoo functions is so that resource allocation can happen in between. Doing it in some other order is just wrong. OpenTemporaryFile() did open(), enlarge, remember, which would leak the open file if the enlarge step ran out of memory. Because fd.c has its own layer of resource-remembering, the consequences look like they'd be limited to an intratransaction FD leak, but it's still not good. IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow up if the incr-refcount step ever failed. It was safe enough when written, but since the introduction of PrivateRefCountHash, I think the assumption that no error could happen there is pretty shaky. The odds of real problems from either bug are probably small, but still, back-patch to supported branches. Thomas Munro and Tom Lane, per a comment from Andres Freund Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d7f59347bc06cb26fe3eff283f9104ac1b26d177 Modified Files -- src/backend/storage/buffer/bufmgr.c | 2 +- src/backend/storage/file/fd.c | 10 -- 2 files changed, 9 insertions(+), 3 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 two violations of the ResourceOwnerEnlarge/Remember protocol
Fix two violations of the ResourceOwnerEnlarge/Remember protocol. The point of having separate ResourceOwnerEnlargeFoo and ResourceOwnerRememberFoo functions is so that resource allocation can happen in between. Doing it in some other order is just wrong. OpenTemporaryFile() did open(), enlarge, remember, which would leak the open file if the enlarge step ran out of memory. Because fd.c has its own layer of resource-remembering, the consequences look like they'd be limited to an intratransaction FD leak, but it's still not good. IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow up if the incr-refcount step ever failed. It was safe enough when written, but since the introduction of PrivateRefCountHash, I think the assumption that no error could happen there is pretty shaky. The odds of real problems from either bug are probably small, but still, back-patch to supported branches. Thomas Munro and Tom Lane, per a comment from Andres Freund Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1786cdab113701f154ca804537fe1c21d23e4ce8 Modified Files -- src/backend/storage/buffer/bufmgr.c | 2 +- src/backend/storage/file/fd.c | 10 -- 2 files changed, 9 insertions(+), 3 deletions(-) -- 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: Remove secondary checkpoint
Andres Freund <and...@anarazel.de> writes:
> I think you misunderstand my point - I'm saying that pg_resetxlog should
> be able to force the use of older checkpoints, basically as a fallback
> to cases where the previous approach might actually have worked, not
> that it needs to work across format changes.
That seems like a completely separate feature --- and one of dubious
value, frankly. The further back you go, the less likely it'd be
to work.
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
Re: [COMMITTERS] pgsql: Remove secondary checkpoint
Andres Freund <and...@anarazel.de> writes:
> On 2017-11-07 17:57:31 +, Simon Riggs wrote:
>> Remove secondary checkpoint
> FWIW, I don't think this should be applied without a pg_resetxlog
> feature allowing to manually use older checkpoints.
Uh, what? We have never before insisted on pg_resetxlog being able
to use WAL across a WAL format change, and there have been many of
those.
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] pgsql: Fix unportable spelling of int64 constant.
Fix unportable spelling of int64 constant. Per buildfarm member pademelon. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/92a1834dd88e56e823ac6641313a2f077a8af72e Modified Files -- src/include/utils/hashutils.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
[COMMITTERS] pgsql: Fix unportable usage of functions.
Fix unportable usage of functions. isdigit(), isspace(), etc are likely to give surprising results if passed a signed char. We should always cast the argument to unsigned char to avoid that. Error in commit 63d6b97fd, found by buildfarm member gaur. Back-patch to 9.3, like that commit. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e836502d64ba7fc936d8c273125e4ac298773e76 Modified Files -- src/interfaces/ecpg/ecpglib/data.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 unportable usage of functions.
Fix unportable usage of functions. isdigit(), isspace(), etc are likely to give surprising results if passed a signed char. We should always cast the argument to unsigned char to avoid that. Error in commit 63d6b97fd, found by buildfarm member gaur. Back-patch to 9.3, like that commit. Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/806fc522688c45ea40c57fb843775fcea40e0bd4 Modified Files -- src/interfaces/ecpg/ecpglib/data.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 unportable usage of functions.
Fix unportable usage of functions. isdigit(), isspace(), etc are likely to give surprising results if passed a signed char. We should always cast the argument to unsigned char to avoid that. Error in commit 63d6b97fd, found by buildfarm member gaur. Back-patch to 9.3, like that commit. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d1f9ac5b100dbc4da02f0f209a2e7730bd5e83e9 Modified Files -- src/interfaces/ecpg/ecpglib/data.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 unportable usage of functions.
Fix unportable usage of functions. isdigit(), isspace(), etc are likely to give surprising results if passed a signed char. We should always cast the argument to unsigned char to avoid that. Error in commit 63d6b97fd, found by buildfarm member gaur. Back-patch to 9.3, like that commit. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1a93c2536a75e7759420e8f9a95e2076da9135df Modified Files -- src/interfaces/ecpg/ecpglib/data.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 unportable usage of functions.
Fix unportable usage of functions. isdigit(), isspace(), etc are likely to give surprising results if passed a signed char. We should always cast the argument to unsigned char to avoid that. Error in commit 63d6b97fd, found by buildfarm member gaur. Back-patch to 9.3, like that commit. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/941602da1f615bb6c98acbf822a15a99fbc99ecd Modified Files -- src/interfaces/ecpg/ecpglib/data.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 unportable usage of functions.
Fix unportable usage of functions. isdigit(), isspace(), etc are likely to give surprising results if passed a signed char. We should always cast the argument to unsigned char to avoid that. Error in commit 63d6b97fd, found by buildfarm member gaur. Back-patch to 9.3, like that commit. Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7a15fe5a2240244e2f80f25adfe6b9a34787a021 Modified Files -- src/interfaces/ecpg/ecpglib/data.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 version numbering foulups exposed by 10.1.
Fix version numbering foulups exposed by 10.1. configure computed PG_VERSION_NUM incorrectly. (Coulda sworn I tested that logic back when, but it had an obvious thinko.) pg_upgrade had not been taught about the new dispensation with just one part in the major version number. Both things accidentally failed to fail with 10.0, but with 10.1 we got the wrong results. Per buildfarm. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d0c80c17f1a6d0b93d2ca14fe47d83b131ce9108 Modified Files -- configure | 2 +- configure.in| 2 +- src/bin/pg_upgrade/exec.c | 23 ++- src/bin/pg_upgrade/server.c | 18 +- 4 files changed, 29 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
[COMMITTERS] pgsql: Fix version numbering foulups exposed by 10.1.
Fix version numbering foulups exposed by 10.1. configure computed PG_VERSION_NUM incorrectly. (Coulda sworn I tested that logic back when, but it had an obvious thinko.) pg_upgrade had not been taught about the new dispensation with just one part in the major version number. Both things accidentally failed to fail with 10.0, but with 10.1 we got the wrong results. Per buildfarm. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/958fe549884928cd3bdf009993e9a05df5fd6cee Modified Files -- configure | 2 +- configure.in| 2 +- src/bin/pg_upgrade/exec.c | 23 ++- src/bin/pg_upgrade/server.c | 18 +- 4 files changed, 29 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
Re: [COMMITTERS] pgsql: Stamp 9.2.24.
Peter Geoghegan <p...@bowt.ie> writes:
> On Mon, Nov 6, 2017 at 2:47 PM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
>> 9.2.24 is the last of the 9.2-series, November being the last minor
>> release after the 5-year community support window.
> We already removed 9.2 from the website, though.
[ shrug... ] Somebody jumped the gun. Doesn't matter much at
this point, perhaps. But the actual policy about this is what
it says at https://www.postgresql.org/support/versioning/:
The PostgreSQL project aims to fully support a major release for five
years. After its end-of-life (EOL) month ends, a major version
receives one final minor release. After that final minor release, bug
fixing ceases for that major version.
(That para was recently reworded to be more specific, but this is what the
de facto policy has been since we established the five-year target.)
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
Re: [COMMITTERS] pgsql: Stamp 9.2.24.
Peter Geoghegan <p...@bowt.ie> writes:
> Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Stamp 9.2.24.
> Uh, I thought 9.2 was EOL.
Now it is ...
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] pgsql: Stamp 9.2.24.
Stamp 9.2.24. Branch -- REL9_2_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8786f783ab2398468a8c4d8eac937fc6533d16e3 Modified Files -- configure| 18 +- configure.in | 2 +- doc/bug.template | 2 +- src/include/pg_config.h.win32| 8 src/interfaces/libpq/libpq.rc.in | 8 src/port/win32ver.rc | 4 ++-- 6 files changed, 21 insertions(+), 21 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: Stamp 9.4.15.
Stamp 9.4.15. Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/de7dabfd35e8f657af9a54cb0ff3171e1cf8e957 Modified Files -- configure| 18 +- configure.in | 2 +- doc/bug.template | 2 +- src/include/pg_config.h.win32| 8 src/interfaces/libpq/libpq.rc.in | 8 src/port/win32ver.rc | 4 ++-- 6 files changed, 21 insertions(+), 21 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: Stamp 9.5.10.
Stamp 9.5.10. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9ce323f612ab19eda1322bb6cf8227b835027511 Modified Files -- configure| 18 +- configure.in | 2 +- doc/bug.template | 2 +- src/include/pg_config.h.win32| 8 src/interfaces/libpq/libpq.rc.in | 8 src/port/win32ver.rc | 4 ++-- 6 files changed, 21 insertions(+), 21 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: Stamp 9.6.6.
Stamp 9.6.6. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0a13f1966d4cda2eb49dec0324ab5d482bbdd956 Modified Files -- configure| 18 +- configure.in | 2 +- doc/bug.template | 2 +- src/include/pg_config.h.win32| 8 src/interfaces/libpq/libpq.rc.in | 8 src/port/win32ver.rc | 4 ++-- 6 files changed, 21 insertions(+), 21 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: Stamp 10.1.
Stamp 10.1. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0b35d54c6fc4d98f8e8b38770b53c7358ebf Modified Files -- configure| 18 +- configure.in | 2 +- doc/bug.template | 2 +- src/include/pg_config.h.win32| 8 src/interfaces/libpq/libpq.rc.in | 8 src/port/win32ver.rc | 4 ++-- 6 files changed, 21 insertions(+), 21 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: Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24.
Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24. In the v10 branch, also back-patch the effects of 1ff01b390 and c29c57890 on these files, to reduce future maintenance issues. (I'd do it further back, except that the 9.X branches differ anyway due to xlog-to-wal link tag renaming.) Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/992c3eb1276e6f6abaac8c4ac8dfcfe3421f8a6e Modified Files -- doc/src/sgml/release-10.sgml | 682 +- doc/src/sgml/release-9.2.sgml | 2894 ++--- doc/src/sgml/release-9.3.sgml | 2750 +-- doc/src/sgml/release-9.4.sgml | 2438 ++ doc/src/sgml/release-9.5.sgml | 2114 +- doc/src/sgml/release-9.6.sgml | 2028 ++--- 6 files changed, 7470 insertions(+), 5436 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: Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24.
Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24. In the v10 branch, also back-patch the effects of 1ff01b390 and c29c57890 on these files, to reduce future maintenance issues. (I'd do it further back, except that the 9.X branches differ anyway due to xlog-to-wal link tag renaming.) Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0f894849b7ea3a6d6eb97ef135ed8ca89b1d4480 Modified Files -- doc/src/sgml/release-9.2.sgml | 176 ++ doc/src/sgml/release-9.3.sgml | 192 ++ 2 files changed, 368 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: Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24.
Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24. In the v10 branch, also back-patch the effects of 1ff01b390 and c29c57890 on these files, to reduce future maintenance issues. (I'd do it further back, except that the 9.X branches differ anyway due to xlog-to-wal link tag renaming.) Branch -- REL9_2_STABLE Details --- https://git.postgresql.org/pg/commitdiff/50714dd8606015d4307fc8edc931a56c142ce8e4 Modified Files -- doc/src/sgml/release-9.2.sgml | 176 ++ 1 file changed, 176 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: Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24.
Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24. In the v10 branch, also back-patch the effects of 1ff01b390 and c29c57890 on these files, to reduce future maintenance issues. (I'd do it further back, except that the 9.X branches differ anyway due to xlog-to-wal link tag renaming.) Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/efa7dfaf7334b9cc8b40e36cd1d507674b8ea9fc Modified Files -- doc/src/sgml/release-9.2.sgml | 176 +++ doc/src/sgml/release-9.3.sgml | 192 doc/src/sgml/release-9.4.sgml | 236 doc/src/sgml/release-9.5.sgml | 288 doc/src/sgml/release-9.6.sgml | 506 ++ 5 files changed, 1398 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: Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24.
Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24. In the v10 branch, also back-patch the effects of 1ff01b390 and c29c57890 on these files, to reduce future maintenance issues. (I'd do it further back, except that the 9.X branches differ anyway due to xlog-to-wal link tag renaming.) Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/168b41b65b83275977b1eae4cb1a42cadf9e8e80 Modified Files -- doc/src/sgml/release-9.2.sgml | 176 +++ doc/src/sgml/release-9.3.sgml | 192 ++ doc/src/sgml/release-9.4.sgml | 236 ++ 3 files changed, 604 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: Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24.
Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24. In the v10 branch, also back-patch the effects of 1ff01b390 and c29c57890 on these files, to reduce future maintenance issues. (I'd do it further back, except that the 9.X branches differ anyway due to xlog-to-wal link tag renaming.) Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b35b185bf705c4dbaf21198c81b3d85f4a96804a Modified Files -- doc/src/sgml/release-10.sgml | 253 ++--- doc/src/sgml/release-9.2.sgml | 176 +++ doc/src/sgml/release-9.3.sgml | 192 doc/src/sgml/release-9.4.sgml | 236 doc/src/sgml/release-9.5.sgml | 288 doc/src/sgml/release-9.6.sgml | 506 ++ 6 files changed, 1412 insertions(+), 239 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: Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24.
Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24. In the v10 branch, also back-patch the effects of 1ff01b390 and c29c57890 on these files, to reduce future maintenance issues. (I'd do it further back, except that the 9.X branches differ anyway due to xlog-to-wal link tag renaming.) Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eb0080401100ccff730983a0d08d0787ff6f5b32 Modified Files -- doc/src/sgml/release-9.2.sgml | 176 ++ doc/src/sgml/release-9.3.sgml | 192 doc/src/sgml/release-9.4.sgml | 236 ++ doc/src/sgml/release-9.5.sgml | 288 ++ 4 files changed, 892 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: First-draft release notes for 10.1.
First-draft release notes for 10.1. As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first. Note that a fair percentage of the entries apply only to prior branches because their issue was already fixed in 10.0. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/42de8a0255c2509bf179205e94b9d65f9d6f3cf9 Modified Files -- doc/src/sgml/release-10.sgml | 861 +++ 1 file changed, 861 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: Avoid looping through line pointers twice in PageRepairFragmenta
Avoid looping through line pointers twice in PageRepairFragmentation(). There doesn't seem to be any good reason to do the filling of the itemidbase[] array separately from the first traversal of the pointers. It's certainly not a win if there are any line pointers with storage, and even if there aren't, this change doesn't insert code into the part of the first loop that will be traversed in that case. So let's just merge the two loops. Yura Sokolov, reviewed by Claudio Freire Discussion: https://postgr.es/m/e49befcc6f1d7099834c6fdf5c675...@postgrespro.ru Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a9169f0200fc57e01cbd216bbd41c9ea3a79a7b0 Modified Files -- src/backend/storage/page/bufpage.c | 46 +- 1 file changed, 21 insertions(+), 25 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: Flag index metapages as standard-format in xlog.c calls.
Flag index metapages as standard-format in xlog.c calls. btree, hash, and bloom indexes all set up their metapages in standard format (that is, with pd_lower and pd_upper correctly delimiting the unused area); but they mostly didn't inform the xlog routines of this. When calling log_newpage[_buffer], this is bad because it loses the opportunity to compress unused data out of the WAL record. When calling XLogRegisterBuffer, it's not such a performance problem because all of these call sites also use REGBUF_WILL_INIT, preventing an FPI image from being written. But it's still a good idea to provide the flag when relevant, because that aids WAL consistency checking. This completes the project of getting all the in-core index AMs to handle their metapage WAL operations similarly. Amit Kapila, reviewed by Michael Paquier Discussion: https://postgr.es/m/0d273805-0e9e-ec1a-cb84-d4da400b8...@lab.ntt.co.jp Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4c11d2c559e76892156fd08d6a3cf5e1848a017f Modified Files -- contrib/bloom/blinsert.c | 2 +- src/backend/access/hash/hashpage.c| 7 --- src/backend/access/nbtree/nbtinsert.c | 4 ++-- src/backend/access/nbtree/nbtpage.c | 9 + src/backend/access/nbtree/nbtree.c| 2 +- src/backend/access/nbtree/nbtxlog.c | 5 +++-- 6 files changed, 16 insertions(+), 13 deletions(-) -- 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: Fix BRIN summarization concurrent with extension
Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Fix BRIN summarization concurrent with extension Buildfarm is entirely unhappy ... 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] pgsql: pgbench: replace run-time string comparisons with an enum identi
pgbench: replace run-time string comparisons with an enum identifier. Minor refactoring that should yield some performance benefit. Fabien Coelho, reviewed by Aleksandr Parfenov Discussion: https://postgr.es/m/alpine.DEB.2.20.1709230538130.4999@lancre Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f987f83de20afe3ba78be1e15db5dffe7488faa7 Modified Files -- src/bin/pgbench/pgbench.c | 62 ++- 1 file changed, 51 insertions(+), 11 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: Set the metapage's pd_lower correctly in brin, gin, and spgist i
Set the metapage's pd_lower correctly in brin, gin, and spgist indexes. Previously, these index types left the pd_lower field set to the default SizeOfPageHeaderData, which is really a lie because it ought to point past whatever space is being used for metadata. The coding accidentally failed to fail because we never told xlog.c that the metapage is of standard format --- but that's not very good, because it impedes WAL consistency checking, and in some cases prevents compression of full-page images. To fix, ensure that we set pd_lower correctly, not only when creating a metapage but whenever we write it out (these apparently redundant steps are needed to cope with pg_upgrade'd indexes that don't yet contain the right value). This allows telling xlog.c that the page is of standard format. The WAL consistency check mask functions are made to mask only if pd_lower appears valid, which I think is likely unnecessary complication, since any metapage appearing in a v11 WAL stream should contain valid pd_lower. But it doesn't cost much to be paranoid. Amit Langote, reviewed by Michael Paquier and Amit Kapila Discussion: https://postgr.es/m/0d273805-0e9e-ec1a-cb84-d4da400b8...@lab.ntt.co.jp Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/81e334ce4e6d687d548e60ad8954b7dfd9e568a2 Modified Files -- src/backend/access/brin/brin.c | 4 ++-- src/backend/access/brin/brin_pageops.c | 10 +- src/backend/access/brin/brin_revmap.c | 15 +-- src/backend/access/brin/brin_xlog.c| 21 +++-- src/backend/access/gin/ginfast.c | 26 +++--- src/backend/access/gin/gininsert.c | 4 ++-- src/backend/access/gin/ginutil.c | 20 +++- src/backend/access/gin/ginxlog.c | 25 ++--- src/backend/access/spgist/spginsert.c | 4 ++-- src/backend/access/spgist/spgutils.c | 24 ++-- src/backend/access/spgist/spgxlog.c| 7 --- 11 files changed, 125 insertions(+), 35 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Robert Haas <robertmh...@gmail.com> writes:
> Well, my thought was that delaying this release for a week would be
> better than either (a) doing an extra minor release just to get this
> fix out or (b) waiting another three months to release this fix. The
> former seems like fairly unnecessary work, and the latter doesn't seem
> particularly responsible. Users can't reasonably expect us to fix
> data-loss-causing bugs that we don't know about yet, but they can
> reasonably expect us to issue fixes promptly for ones that we do know
> about.
Our experience with "hold the release waiting for a fix for bug X"
decisions has been consistently bad. Furthermore, if we can't produce
a patch we trust by Monday, I would much rather that we not do it
in a rushed fashion at all. I think it would be entirely reasonable
to consider making off-cadence releases in, perhaps, a month, once
the dust is entirely settled.
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
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Robert Haas <robertmh...@gmail.com> writes: > Just to be clear, it looks like "Fix freezing of a dead HOT-updated > tuple" (46c35116ae1acc8826705ef2a7b5d9110f9d6e84) went in before 10.0 > was stamped, but "Fix traversal of half-frozen update chains" > (22576734b805fb0952f9be841ca8f643694ee868) went in afterwards and is > therefore unreleased at present. Thanks for doing this analysis of the actual effects in 10.0. > Personally, I think it would be best to push the release out a week. I would only be in favor of that if there were some reason to think that the bug is worse now than it's been in the four years since 9.3 was released. Otherwise, we should ship the bug fixes we have on-schedule. I think it's a very very safe bet that there are other data-loss-causing bugs in there, so I see no good reason for panicking over this one. > ... and (I know you're all tired of hearing me say this) patches that > implicate the on-disk format are scary. Agreed, but how is that relevant now that the bogus patches are reverted? 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] pgsql: Fix corner-case errors in brin_doupdate().
Fix corner-case errors in brin_doupdate(). In some cases the BRIN code releases lock on an index page, and later re-acquires lock and tries to check that the tuple it was working on is still there. That check was a couple bricks shy of a load. It didn't consider that the page might have turned into a "revmap" page. (The samepage code path doesn't call brin_getinsertbuffer(), so it isn't protected by the checks for revmap status there.) It also didn't check whether the tuple offset was now off the end of the linepointer array. Since commit 24992c6db the latter case is pretty common, but at least in principle it could have occurred before that. The net result is that concurrent updates of a BRIN index could fail with errors like "invalid index offnum" or "inconsistent range map". Per report from Tomas Vondra. Back-patch to 9.5, since this code is substantially the same in all versions containing BRIN. Discussion: https://postgr.es/m/10d2b9f9-f427-03b8-8ad9-6af4ecacb...@2ndquadrant.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/97ba7b8c87e13112fd31d936507e7d060a297aa4 Modified Files -- src/backend/access/brin/brin_pageops.c | 10 -- 1 file changed, 8 insertions(+), 2 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 corner-case errors in brin_doupdate().
Fix corner-case errors in brin_doupdate(). In some cases the BRIN code releases lock on an index page, and later re-acquires lock and tries to check that the tuple it was working on is still there. That check was a couple bricks shy of a load. It didn't consider that the page might have turned into a "revmap" page. (The samepage code path doesn't call brin_getinsertbuffer(), so it isn't protected by the checks for revmap status there.) It also didn't check whether the tuple offset was now off the end of the linepointer array. Since commit 24992c6db the latter case is pretty common, but at least in principle it could have occurred before that. The net result is that concurrent updates of a BRIN index could fail with errors like "invalid index offnum" or "inconsistent range map". Per report from Tomas Vondra. Back-patch to 9.5, since this code is substantially the same in all versions containing BRIN. Discussion: https://postgr.es/m/10d2b9f9-f427-03b8-8ad9-6af4ecacb...@2ndquadrant.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a43cd427e7033771645abd4f9dbd2b1b2ab5ed5c Modified Files -- src/backend/access/brin/brin_pageops.c | 10 -- 1 file changed, 8 insertions(+), 2 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 corner-case errors in brin_doupdate().
Fix corner-case errors in brin_doupdate(). In some cases the BRIN code releases lock on an index page, and later re-acquires lock and tries to check that the tuple it was working on is still there. That check was a couple bricks shy of a load. It didn't consider that the page might have turned into a "revmap" page. (The samepage code path doesn't call brin_getinsertbuffer(), so it isn't protected by the checks for revmap status there.) It also didn't check whether the tuple offset was now off the end of the linepointer array. Since commit 24992c6db the latter case is pretty common, but at least in principle it could have occurred before that. The net result is that concurrent updates of a BRIN index could fail with errors like "invalid index offnum" or "inconsistent range map". Per report from Tomas Vondra. Back-patch to 9.5, since this code is substantially the same in all versions containing BRIN. Discussion: https://postgr.es/m/10d2b9f9-f427-03b8-8ad9-6af4ecacb...@2ndquadrant.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/62a16572d5714bfb19e2a273e61218be6682d3df Modified Files -- src/backend/access/brin/brin_pageops.c | 10 -- 1 file changed, 8 insertions(+), 2 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 corner-case errors in brin_doupdate().
Fix corner-case errors in brin_doupdate(). In some cases the BRIN code releases lock on an index page, and later re-acquires lock and tries to check that the tuple it was working on is still there. That check was a couple bricks shy of a load. It didn't consider that the page might have turned into a "revmap" page. (The samepage code path doesn't call brin_getinsertbuffer(), so it isn't protected by the checks for revmap status there.) It also didn't check whether the tuple offset was now off the end of the linepointer array. Since commit 24992c6db the latter case is pretty common, but at least in principle it could have occurred before that. The net result is that concurrent updates of a BRIN index could fail with errors like "invalid index offnum" or "inconsistent range map". Per report from Tomas Vondra. Back-patch to 9.5, since this code is substantially the same in all versions containing BRIN. Discussion: https://postgr.es/m/10d2b9f9-f427-03b8-8ad9-6af4ecacb...@2ndquadrant.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/43276abc6f7e497bfca2277b9e04585fcd6c25c5 Modified Files -- src/backend/access/brin/brin_pageops.c | 10 -- 1 file changed, 8 insertions(+), 2 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: Teach planner to account for HAVING quals in aggregation plan no
Teach planner to account for HAVING quals in aggregation plan nodes. For some reason, we have never accounted for either the evaluation cost or the selectivity of filter conditions attached to Agg and Group nodes (which, in practice, are always conditions from a HAVING clause). Applying our regular selectivity logic to post-grouping conditions is a bit bogus, but it's surely better than taking the selectivity as 1.0. Perhaps someday the extended-statistics mechanism can be taught to provide statistics that would help us in getting non-default estimates here. Per a gripe from Benjamin Coutu. This is surely a bug fix, but I'm hesitant to back-patch because of the prospect of destabilizing existing plan choices. Given that it took us this long to notice the bug, it's probably not hurting too many people in the field. Discussion: https://postgr.es/m/20968.1509486...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7b6c07547190f056b0464098bb5a2247129d7aa2 Modified Files -- src/backend/optimizer/path/costsize.c | 46 +- src/backend/optimizer/prep/prepunion.c | 2 ++ src/backend/optimizer/util/pathnode.c | 25 ++ src/include/optimizer/cost.h | 2 ++ 4 files changed, 74 insertions(+), 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
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Andres Freund <and...@anarazel.de> writes:
> Do we care about people upgrading to unreleased versions? We could do
> nothing, document it in the release notes, or ???
Do nothing.
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] pgsql: Doc: update URL for check_postgres.
Doc: update URL for check_postgres. Reported by Dan Vianello. Discussion: https://postgr.es/m/e6e12f18f70e46848c058084d42fb...@kstlmexgp001.corp.chartercom.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1048afc864e84b4f206bb7edd3773b49f1d8cc5b Modified Files -- doc/src/sgml/maintenance.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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: Doc: update URL for check_postgres.
Doc: update URL for check_postgres. Reported by Dan Vianello. Discussion: https://postgr.es/m/e6e12f18f70e46848c058084d42fb...@kstlmexgp001.corp.chartercom.com Branch -- REL9_2_STABLE Details --- https://git.postgresql.org/pg/commitdiff/13406fe23d3c6f3889014df6c001eb8652114a64 Modified Files -- doc/src/sgml/maintenance.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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: Doc: update URL for check_postgres.
Doc: update URL for check_postgres. Reported by Dan Vianello. Discussion: https://postgr.es/m/e6e12f18f70e46848c058084d42fb...@kstlmexgp001.corp.chartercom.com Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e89867c033291b01614cb1a0e6fe76ce4c478ea6 Modified Files -- doc/src/sgml/maintenance.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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: Doc: update URL for check_postgres.
Doc: update URL for check_postgres. Reported by Dan Vianello. Discussion: https://postgr.es/m/e6e12f18f70e46848c058084d42fb...@kstlmexgp001.corp.chartercom.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7ae39519bf0eca229f7ae98a391b161c43fe88a9 Modified Files -- doc/src/sgml/maintenance.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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: Doc: update URL for check_postgres.
Doc: update URL for check_postgres. Reported by Dan Vianello. Discussion: https://postgr.es/m/e6e12f18f70e46848c058084d42fb...@kstlmexgp001.corp.chartercom.com Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f570ec5181e1aeff4fc8ea229e50bd666d35062f Modified Files -- doc/src/sgml/maintenance.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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: Doc: update URL for check_postgres.
Doc: update URL for check_postgres. Reported by Dan Vianello. Discussion: https://postgr.es/m/e6e12f18f70e46848c058084d42fb...@kstlmexgp001.corp.chartercom.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c0e2062d3214f6230a0e1eee9236b202bda9221f Modified Files -- doc/src/sgml/maintenance.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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: Doc: update URL for check_postgres.
Doc: update URL for check_postgres. Reported by Dan Vianello. Discussion: https://postgr.es/m/e6e12f18f70e46848c058084d42fb...@kstlmexgp001.corp.chartercom.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1cf96d6c7169d0eb21770eac67b60c12dcaf113c Modified Files -- doc/src/sgml/maintenance.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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: Allow bitmap scans to operate as index-only scans when possible.
Allow bitmap scans to operate as index-only scans when possible. If we don't have to return any columns from heap tuples, and there's no need to recheck qual conditions, and the heap page is all-visible, then we can skip fetching the heap page altogether. Skip prefetching pages too, when possible, on the assumption that the recheck flag will remain the same from one page to the next. While that assumption is hardly bulletproof, it seems like a good bet most of the time, and better than prefetching pages we don't need. This commit installs the executor infrastructure, but doesn't change any planner cost estimates, thus possibly causing bitmap scans to not be chosen in cases where this change renders them the best choice. I (tgl) am not entirely convinced that we need to account for this behavior in the planner, because I think typically the bitmap scan would get chosen anyway if it's the best bet. In any case the submitted patch took way too many shortcuts, resulting in too many clearly-bad choices, to be committable. Alexander Kuzmenkov, reviewed by Alexey Chernyshov, and whacked around rather heavily by me. Discussion: https://postgr.es/m/239a8955-c0fc-f506-026d-c837e86c8...@postgrespro.ru Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7c70996ebf0949b142a99c9445061c3c83ce62b3 Modified Files -- src/backend/executor/nodeBitmapHeapscan.c | 165 +++--- src/backend/optimizer/plan/createplan.c | 9 ++ src/include/nodes/execnodes.h | 10 +- src/test/regress/expected/stats.out | 3 + src/test/regress/sql/stats.sql| 3 + 5 files changed, 150 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 code to update domain constraints when needed.
Fix ALTER TABLE code to update domain constraints when needed. It's possible for dropping a column, or altering its type, to require changes in domain CHECK constraint expressions; but the code was previously only expecting to find dependent table CHECK constraints. Make the necessary adjustments. This is a fairly old oversight, but it's a lot easier to encounter the problem in the context of domains over composite types than it was before. Given the lack of field complaints, I'm not going to bother with a back-patch, though I'd be willing to reconsider that decision if someone does complain. Patch by me, reviewed by Michael Paquier Discussion: https://postgr.es/m/30656.1509128...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/af20e2d728eb508bb169e7294e4e210a3459833a Modified Files -- src/backend/commands/tablecmds.c | 98 ++-- src/backend/utils/adt/ruleutils.c| 67 src/include/nodes/parsenodes.h | 1 + src/test/regress/expected/domain.out | 25 + src/test/regress/sql/domain.sql | 20 5 files changed, 186 insertions(+), 25 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 underqualified cast-target type names in pg_dump and psql qu
Fix underqualified cast-target type names in pg_dump and psql queries. Queries running with some non-pg_catalog schema frontmost in their search path need to be careful to schema-qualify type names that should be sought in pg_catalog. Vitaly Burovoy reported an oversight of this sort in pg_dump's dumpSequence, and grepping detected another one in psql's describeOneTableDetails, both introduced by sequence-related changes in v10. In pg_dump, we can fix things by removing the cast altogether, since it doesn't really matter what data types are reported for these query result columns. Likewise in psql, the query seemed to be working unduly hard to get a result that's guaranteed to be exactly 'bigint'. I also changed a couple of occurrences of "::char" similarly. These are not bugs, since "char" is a typename keyword and not subject to search_path rules, but it seems better to use uniform style. Vitaly Burovoy and Tom Lane Discussion: https://postgr.es/m/CAKOSWN=ds66zlw2sqkltm8wbxfgdbc_odkmt3djfpt2me5k...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/080351466c5a669bf35a323bdec9e296330a5dbb Modified Files -- src/bin/pg_dump/pg_dump.c | 9 ++--- src/bin/psql/describe.c | 4 ++-- 2 files changed, 8 insertions(+), 5 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 underqualified cast-target type names in pg_dump and psql qu
Fix underqualified cast-target type names in pg_dump and psql queries. Queries running with some non-pg_catalog schema frontmost in their search path need to be careful to schema-qualify type names that should be sought in pg_catalog. Vitaly Burovoy reported an oversight of this sort in pg_dump's dumpSequence, and grepping detected another one in psql's describeOneTableDetails, both introduced by sequence-related changes in v10. In pg_dump, we can fix things by removing the cast altogether, since it doesn't really matter what data types are reported for these query result columns. Likewise in psql, the query seemed to be working unduly hard to get a result that's guaranteed to be exactly 'bigint'. I also changed a couple of occurrences of "::char" similarly. These are not bugs, since "char" is a typename keyword and not subject to search_path rules, but it seems better to use uniform style. Vitaly Burovoy and Tom Lane Discussion: https://postgr.es/m/CAKOSWN=ds66zlw2sqkltm8wbxfgdbc_odkmt3djfpt2me5k...@mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9cf2b854a59d227eaec3d97780e986ebdd0c6854 Modified Files -- src/bin/pg_dump/pg_dump.c | 9 ++--- src/bin/psql/describe.c | 4 ++-- 2 files changed, 8 insertions(+), 5 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: Doc: call out UPDATE syntax change as a v10 compatibility issue.
Doc: call out UPDATE syntax change as a v10 compatibility issue. The change made by commit 906bfcad7 means that if you're writing a parenthesized column list in UPDATE ... SET, but that column list is only one column, you now need to write ROW(expression) on the righthand side, not just a parenthesized expression. This was an intentional change for spec compatibility and potential future expansion of the possibilities for the RHS, but I'd neglected to document it as a compatibility issue, figuring that hardly anyone would bother with parenthesized syntax for a single target column. I was wrong, as shown by questions from Justin Pryzby, Adam Brusselback, and others. Move the release note item into the compatibility section and point out the behavior change for a single target column. Discussion: https://postgr.es/m/camjna7cdlzpcs0xnrpkvqmj6vb6g3eh8cygp9zbjxdpfftz...@mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7becb5fa1d8760ee70258ff23ce229ce5451c597 Modified Files -- doc/src/sgml/release-10.sgml | 46 +--- 1 file changed, 26 insertions(+), 20 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: Doc: call out UPDATE syntax change as a v10 compatibility issue.
Doc: call out UPDATE syntax change as a v10 compatibility issue. The change made by commit 906bfcad7 means that if you're writing a parenthesized column list in UPDATE ... SET, but that column list is only one column, you now need to write ROW(expression) on the righthand side, not just a parenthesized expression. This was an intentional change for spec compatibility and potential future expansion of the possibilities for the RHS, but I'd neglected to document it as a compatibility issue, figuring that hardly anyone would bother with parenthesized syntax for a single target column. I was wrong, as shown by questions from Justin Pryzby, Adam Brusselback, and others. Move the release note item into the compatibility section and point out the behavior change for a single target column. Discussion: https://postgr.es/m/camjna7cdlzpcs0xnrpkvqmj6vb6g3eh8cygp9zbjxdpfftz...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/86182b18957b8f9e8045d55b137aeef7c9af9916 Modified Files -- doc/src/sgml/release-10.sgml | 46 +--- 1 file changed, 26 insertions(+), 20 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: Support domains over composite types in PL/Perl.
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/60651e4cddbb77e8f1a0c7fc0be6a7e7bf626fe0 Modified Files -- src/pl/plperl/expected/plperl.out | 88 ++-- src/pl/plperl/expected/plperl_util.out | 11 +++- src/pl/plperl/plperl.c | 103 ++--- src/pl/plperl/sql/plperl.sql | 49 src/pl/plperl/sql/plperl_util.sql | 9 +++ 5 files changed, 222 insertions(+), 38 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: Dept of second thoughts: keep aliasp_item in sync with tlistitem
Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the aliasp_item whether or not we're preparing a colnames list. Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e06b9e9dc8377598d53791f340b8a973c6513b98 Modified Files -- src/backend/parser/parse_relation.c | 3 ++- 1 file changed, 2 insertions(+), 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: Dept of second thoughts: keep aliasp_item in sync with tlistitem
Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the aliasp_item whether or not we're preparing a colnames list. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1f81c2cd524e0c65a621d280255be559ab630e4a Modified Files -- src/backend/parser/parse_relation.c | 3 ++- 1 file changed, 2 insertions(+), 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: Dept of second thoughts: keep aliasp_item in sync with tlistitem
Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the aliasp_item whether or not we're preparing a colnames list. Branch -- REL9_2_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a4c11c103164be667eef362157b48469ed2d0c10 Modified Files -- src/backend/parser/parse_relation.c | 3 ++- 1 file changed, 2 insertions(+), 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
