pgsql: docs: clarify that CREATE TABLE ... _AS_ can be parallelized
docs: clarify that CREATE TABLE ... _AS_ can be parallelized CREATE TABLE without AS doesn't have anything to parallelize. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/25468994cab87ab7e946b6866937ee642fc1261d Modified Files -- doc/src/sgml/parallel.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: adminpack: Revoke EXECUTE on pg_logfile_rotate()
adminpack: Revoke EXECUTE on pg_logfile_rotate() In 9.6, we moved a number of functions over to using the GRANT system to control access instead of having hard-coded superuser checks. As it turns out, adminpack was creating another function in the catalog for one of those backend functions where the superuser check was removed, specifically pg_rotate_logfile(), but it didn't get the memo about having to REVOKE EXECUTE on the alternative-name function (pg_logfile_rotate()), meaning that in any installations with adminpack on 9.6 and higher, any user is able to run the pg_logfile_rotate() function, which then calls pg_rotate_logfile() and rotates the logfile. Fix by adding a new version of adminpack (1.1) which handles the REVOKE. As this function should have only been available to the superuser, this is a security issue, albeit a minor one. Security: CVE-2018-1115 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/53b79ab4fe722b1030b7e9a1580b283fca956e30 Modified Files -- contrib/adminpack/Makefile| 2 +- contrib/adminpack/adminpack--1.0--1.1.sql | 6 contrib/adminpack/adminpack--1.1.sql | 55 +++ contrib/adminpack/adminpack.control | 2 +- 4 files changed, 63 insertions(+), 2 deletions(-)
pgsql: adminpack: Revoke EXECUTE on pg_logfile_rotate()
adminpack: Revoke EXECUTE on pg_logfile_rotate() In 9.6, we moved a number of functions over to using the GRANT system to control access instead of having hard-coded superuser checks. As it turns out, adminpack was creating another function in the catalog for one of those backend functions where the superuser check was removed, specifically pg_rotate_logfile(), but it didn't get the memo about having to REVOKE EXECUTE on the alternative-name function (pg_logfile_rotate()), meaning that in any installations with adminpack on 9.6 and higher, any user is able to run the pg_logfile_rotate() function, which then calls pg_rotate_logfile() and rotates the logfile. Fix by adding a new version of adminpack (1.1) which handles the REVOKE. As this function should have only been available to the superuser, this is a security issue, albeit a minor one. Security: CVE-2018-1115 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/20f01fc45996238f7f1007ba704d30663955150a Modified Files -- contrib/adminpack/Makefile| 2 +- contrib/adminpack/adminpack--1.0--1.1.sql | 6 ++ contrib/adminpack/adminpack.control | 2 +- 3 files changed, 8 insertions(+), 2 deletions(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2018-1115 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/27a65851801c41c66d72d8c55ffab093419da793 Modified Files -- doc/src/sgml/release-10.sgml | 44 --- doc/src/sgml/release-9.6.sgml | 38 ++--- 2 files changed, 76 insertions(+), 6 deletions(-)
pgsql: adminpack: Revoke EXECUTE on pg_logfile_rotate()
adminpack: Revoke EXECUTE on pg_logfile_rotate() In 9.6, we moved a number of functions over to using the GRANT system to control access instead of having hard-coded superuser checks. As it turns out, adminpack was creating another function in the catalog for one of those backend functions where the superuser check was removed, specifically pg_rotate_logfile(), but it didn't get the memo about having to REVOKE EXECUTE on the alternative-name function (pg_logfile_rotate()), meaning that in any installations with adminpack on 9.6 and higher, any user is able to run the pg_logfile_rotate() function, which then calls pg_rotate_logfile() and rotates the logfile. Fix by adding a new version of adminpack (1.1) which handles the REVOKE. As this function should have only been available to the superuser, this is a security issue, albeit a minor one. In HEAD, move the changes implemented for adminpack up to be adminpack 2.0 instead of 1.1. Security: CVE-2018-1115 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7b347409fa2776fbaa4ec9c57365f48a2bbdb80c Modified Files -- contrib/adminpack/Makefile| 2 +- contrib/adminpack/adminpack--1.0--1.1.sql | 47 +--- contrib/adminpack/adminpack--1.1--2.0.sql | 51 +++ contrib/adminpack/adminpack.control | 2 +- 4 files changed, 54 insertions(+), 48 deletions(-)
pgsql: Various improvements of skipping index scan during vacuum techni
Various improvements of skipping index scan during vacuum technics - Change vacuum_cleanup_index_scale_factor GUC to PGC_USERSET. vacuum_cleanup_index_scale_factor GUC was defined as PGC_SIGHUP. But this GUC affects not only autovacuum. So it might be useful to change it from user session in order to influence manually runned VACUUM. - Add missing tab-complete support for vacuum_cleanup_index_scale_factor reloption. - Fix condition for B-tree index cleanup. Zero value of vacuum_cleanup_index_scale_factor means that user wants B-tree index cleanup to be never skipped. - Documentation and comment improvements Authors: Justin Pryzby, Alexander Korotkov, Liudmila Mantrova Reviewed by: all authors and Robert Haas Discussion: https://www.postgresql.org/message-id/flat/20180502023025.GD7631%40telsasoft.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8e12f4a250d250a89153da2eb9b91c31bb80c483 Modified Files -- doc/src/sgml/config.sgml| 35 +++ src/backend/access/nbtree/nbtpage.c | 2 +- src/backend/access/nbtree/nbtree.c | 19 ++- src/backend/utils/misc/guc.c| 2 +- src/bin/psql/tab-complete.c | 6 -- 5 files changed, 43 insertions(+), 21 deletions(-)
