Correctifs appliqués

Peter Eisentraut pushed:

Robert Haas pushed:

Tom Lane pushed:

  • Last-minute updates for release notes. The set of functions that need parallel-safety adjustments isn't the same in 9.6 as 10, so I shouldn't have blindly back-patched that list. Adjust as needed. Also, provide examples of the commands to issue.
  • Suppress compiler warnings when building with --enable-dtrace. Most versions of "dtrace -h" drop const qualifiers from the declarations of probe functions (though macOS gets it right). This causes compiler warnings when we pass in pointers to const. Repair by extending our existing post-processing of the probes.h file. To do so, assume that all "char *" arguments should be "const char *"; that seems reasonably safe. Thomas Munro Discussion:
  • Update oidjoins regression test for v11. Commit 86f575948 already manually updated the oidjoins test for the new pg_constraint.conparentid => pg_constraint.oid relationship, but failed to update findoidjoins/README, thus the apparent inconsistency here. Michael Paquier Discussion:
  • Undo extra chattiness of postmaster logs in TAP tests. Commit 6271fceb8 changed to force log_min_messages = debug1 in all TAP tests, without any discussion and without a concrete need for it. This makes some of the TAP tests noticeably slower (although much of that may be due to poorly-written regexes), and for certain it's bloating the buildfarm logs. Revert the change. Discussion:
  • Count heap tuples in non-SnapshotAny path in IndexBuildHeapRangeScan(). Brown-paper-bag bug in commit 7c91a0364: when we rearranged the placement of "reltuples += 1" statements, we missed including one in this code path. The net effect of that was that CREATE INDEX CONCURRENTLY would set the table's pg_class.reltuples to zero, as would index builds done during bootstrap mode. (It seems like parallel index builds ought to fail similarly, but they don't, perhaps because reltuples is computed in some other way. You certainly couldn't figure that out from the abysmally underdocumented parallelism code in this area.) I was led to this by wondering why initdb seemed to have slowed down as a result of 7c91a0364, as is evident in the buildfarm's timing history. The reason is that every system catalog with indexes had pg_class.reltuples = 0 after bootstrap, causing the planner to make some terrible choices for queries in the post-bootstrap steps. On my workstation, this fix causes the runtime of "initdb -N" to drop from ~2.0 sec to ~1.4 sec, which is almost though not quite back to where it was in v10. That's not much of a deal for production use perhaps, but it makes a noticeable difference for buildfarm and "make check-world" runs, which do a lot of initdbs.
  • Improve initdb's query for generating default descriptions a little. While poking into initdb's performance, I noticed that this query wasn't being done very intelligently. By forcing it to execute obj_description() for each pg_proc/pg_operator join row, we were essentially setting up a nestloop join to pg_description, which is not a bright query plan when there are hundreds of outer rows. Convert the check for a "deprecated" operator into a NOT EXISTS so that it can be done as a hashed antijoin. On my workstation this reduces the time for this query from ~ 35ms to ~ 10ms. Which is not a huge win, but it adds up over buildfarm runs. In passing, insert forced query breaks (\n\n, in single-user mode) after each SQL-query file that initdb sources, and after some relatively new queries in setup_privileges(). This doesn't make a lot of difference normally, but it will result in briefer, saner error messages if anything goes wrong.
  • Improve inefficient regexes in vacuumdb TAP test. The regexes used in to check the postmaster log for expected output contained several places with ".*.*", which is underdetermined and can cause exponential runtime growth in Perl's regex matcher (since it's not bright enough not to waste time seeing whether different splits of the same substring would allow a match). We were fortunate that the amount of text in the postmaster log was generally not enough to make the runtime go to the moon; although commit 6271fceb8 had been on the hairy edge of an obvious problem, thanks to its increasing the default log verbosity to DEBUG1. Experimentation shows that anyone who tried to run this test case with an even higher log verbosity would have been in for serious pain. But even at default logging level, fixing this saves several hundred ms on my workstation, more on slower buildfarm members. Remove the extra ".*"s, restoring more-or-less-linear matching speed. Back-patch to 9.4 where the test case was added, mostly in case anyone tries to do related debugging in a back branch. Discussion:
  • Update time zone data files to tzdata release 2018e. DST law changes in North Korea. Redefinition of "daylight savings" in Ireland, as well as for some past years in Namibia and Czechoslovakia. Additional historical corrections for Czechoslovakia. With this change, the IANA database models Irish timekeeping as following "standard time" in summer, and "daylight savings" in winter, so that the daylight savings offset is one hour behind standard time not one hour ahead. This does not change their UTC offset (+1:00 in summer, 0:00 in winter) nor their timezone abbreviations (IST in summer, GMT in winter), though now "IST" is more correctly read as "Irish Standard Time" not "Irish Summer Time". However, the "is_dst" column in the pg_timezone_names view will now be true in winter and false in summer for the Europe/Dublin zone. Similar changes were made for Namibia between 1994 and 2017, and for Czechoslovakia between 1946 and 1947. So far as I can find, no Postgres internal logic cares about which way tm_isdst is reported; in particular, since commit b2cbced9e we do not rely on it to decide how to interpret ambiguous timestamps during DST transitions. So I don't think this change will affect any Postgres behavior other than the timezone-view outputs. Discussion:
  • Last-minute updates for release notes. Security: CVE-2018-1115
  • Doc: fix overenthusiastic markup. I get "WARNING: nested link may be undefined in output: <xref @linkend = 'pgbench'> nested inside parent element link" from this. Also remove some trailing whitespace.

Andrew Dunstan pushed:

Teodor Sigaev pushed:

�lvaro Herrera pushed:

Stephen Frost pushed:

  • 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

Bruce Momjian pushed:

Correctifs en attente

Micha�l Paquier sent in a patch to remove some newlines no longer needed when PQErrorMessage is used.

Alexander Kuzmenkov sent in another revision of a patch to make pg_ctl play better with logrotate.

Amit Langote sent in another revision of a patch to fix how get_partition_operator looks up the operator.

Micha�l Paquier sent in a patch to make guc_malloc/strdup/realloc available to plugins.

Ildar Musin sent in another revision of a patch to add a MAP syntax for arrays.

Robert Haas sent in two revisions of a patch to improve the documentation for parallel append.

Ashutosh Bapat sent in two more revisions of a patch to fix a bug that manifested as expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

�lvaro Herrera sent in another revision of a patch to fix gaps in modules with handling of partitioned indexes.

Craig Ringer sent in another revision of a patch to PANIC when we detect a possible fsync I/O error instead of retrying fsync.

Ashutosh Bapat sent in a patch to add a test case accessing system columns from a trigger function.

Pavel Raiskup sent in a patch to implement shared library symbol versioning and clean up the libpq build to support same.

Tom Lane sent in a patch to check the /etc/localtime symlink for zone name, a test much shorter than the one initdb currently runs.

David Rowley sent in three revisions of a patch to remove a needless additional partition check in INSERT.

Etsuro Fujita sent in two revisions of a patch to modify make_modifytable so that in case of an inherited UPDATE/DELETE, it passes to PlanDirectModify the per-child modified subroot, not the parent root, for the FDW to get the foreign-join RelOptInfo from the given root in PlanDirectModify.

Heikki Linnakangas sent in a patch to add a hook for extensions which can get notified when query cancel or DIE signal is received, then use same for PL/PythonU.

Pavan Deolasee sent in a WIP patch to always clear the minRecoveryPoint after promotion to ensure that crash recovery always run to the end if a just-promoted standby crashes before completing its first regular checkpoint.

Amit Langote sent in a patch to error out even before calling DefineIndex on foreign partitions.

Kyotaro HORIGUCHI sent in another revision of a patch to enable asynchronous execution and use that machinery in the PostgreSQL FDW.

Peter Eisentraut and Tom Lane traded patches to do lazy detoasting.