Correctifs appliqués

Peter Eisentraut pushed:

Robert Haas pushed:

Tom Lane pushed:

  • Avoid dump/reload problems when using both plpython2 and plpython3. Commit 803716013dc1350f installed a safeguard against loading plpython2 and plpython3 at the same time, but asserted that both could still be used in the same database, just not in the same session. However, that's not actually all that practical because dumping and reloading will fail (since both libraries necessarily get loaded into the restoring session). pg_upgrade is even worse, because it checks for missing libraries by loading every .so library mentioned in the entire installation into one session, so that you can have only one across the whole cluster. We can improve matters by not throwing the error immediately in _PG_init, but only when and if we're asked to do something that requires calling into libpython. This ameliorates both of the above situations, since while execution of CREATE LANGUAGE, CREATE FUNCTION, etc will result in loading plpython, it isn't asked to do anything interesting (at least not if check_function_bodies is off, as it will be during a restore). It's possible that this opens some corner-case holes in which a crash could be provoked with sufficient effort. However, since plpython only exists as an untrusted language, any such crash would require superuser privileges, making it "don't do that" not a security issue. To reduce the hazards in this area, the error is still FATAL when it does get thrown. Per a report from Paul Jones. Back-patch to 9.2, which is as far back as the patch applies without work. (It could be made to work in 9.1, but given the lack of previous complaints, I'm disinclined to expend effort so far back. We've been pretty desultory about support for Python 3 in 9.1 anyway.)
  • Use LOAD not actual code execution to pull in plpython library. Commit 866566a690bb9916 is insufficient to prevent dump/reload failures when using transform modules in a database with both plpython2 and plpython3 installed. The reason is that the transform extension scripts use DO blocks as a mechanism to pull in the libpython library before creating the transform function. It's necessary to preload the library because the dynamic loader won't do it for us on every platform, leading to "unresolved symbol" failures when the transform library is loaded. But it's *not* necessary to execute Python code, and doing so will provoke a multiple-Pythons-are-loaded error even after the preceding commit. To fix, use LOAD instead of a DO block. That requires superuser privilege, but creation of a C function does anyway. It also embeds knowledge of the underlying library name for each PL language; but that's wired into the initdb-time contents of pg_pltemplate too, so that doesn't seem like a large problem either. Note that CREATE TRANSFORM as such doesn't call the language module at all. Per a report from Paul Jones. Back-patch to 9.5 where transform modules were introduced.
  • Remove no-longer-needed old-style check for incompatible plpythons. Commit 866566a690bb9916 introduced a new mechanism for incompatible plpythons to detect each other. I left the old mechanism in place, because it seems possible that a plpython predating that commit might be used with one postdating it. (This would require updating plpython3 but not plpython2 or vice versa, but that seems well within the realm of possibility.) However, surely it will not be able to happen in 9.6 or later, so we can delete the old mechanism in HEAD.
  • Run pgindent on src/bin/pg_dump/* To ease doing indent fixups on a couple of patches I have in progress.
  • Access pg_dump's options structs through Archive struct, not directly. Rather than passing around DumpOptions and RestoreOptions as separate arguments, add fields to struct Archive to carry pointers to these objects, and access them through those fields when needed. There already was a RestoreOptions pointer in Archive, though for no obvious reason it was part of the "private" struct rather than out where pg_dump.c could see it. Doing this allows reversion of quite a lot of parameter-addition changes made in commit 0eea8047bf, which is a good thing IMO because this will reduce the code delta between 9.4 and 9.5, probably easing a few future back-patch efforts. Moreover, the previous commit only added a DumpOptions argument to functions that had to have it at the time, which means we could anticipate still more code churn (and more back-patch hazard) as the requirement spread further. I'd hit exactly that problem in my upcoming patch to fix extension membership marking, which is what motivated me to do this.
  • Handle extension members when first setting object dump flags in pg_dump. pg_dump's original approach to handling extension member objects was to run around and clear (or set) their dump flags rather late in its data collection process. Unfortunately, quite a lot of code expects those flags to be valid before that; which was an entirely reasonable expectation before we added extensions. In particular, this explains Karsten Hilbert's recent report of pg_upgrade failing on a database in which an extension has been installed into the pg_catalog schema. Its objects are initially marked as not-to-be-dumped on the strength of their schema, and later we change them to must-dump because we're doing a binary upgrade of their extension; but we've already skipped essential tasks like making associated DO_SHELL_TYPE objects. To fix, collect extension membership data first, and incorporate it in the initial setting of the dump flags, so that those are once again correct from the get-go. This has the undesirable side effect of slightly lengthening the time taken before pg_dump acquires table locks, but testing suggests that the increase in that window is not very much. Along the way, get rid of ugly special-case logic for deciding whether to dump procedural languages, FDWs, and foreign servers; dump decisions for those are now correct up-front, too. In 9.3 and up, this also fixes erroneous logic about when to dump event triggers (basically, they were *always* dumped before). In 9.5 and up, transform objects had that problem too. Since this problem came in with extensions, back-patch to all supported versions.
  • Fix build_grouping_chain() to not clobber its input lists. There's no good reason for stomping on the input data; it makes the logic in this function no simpler, in fact probably the reverse. And it makes it impossible to separate path generation from plan generation, as I'm working towards doing; that will require more than one traversal of these lists.
  • Remove dead code in pg_dump. Coverity quite reasonably complained that this check for fout==NULL occurred after we'd already dereferenced fout. However, the check is just dead code since there is no code path by which CreateArchive can return a null pointer. Errors such as can't-open-that-file are reported down inside CreateArchive, and control doesn't return. So let's silence the warning by removing the dead code, rather than continuing to pretend it does something. Coverity didn't complain about this before 5b5fea2a1, so back-patch to 9.5 like that patch.

Simon Riggs pushed:

Magnus Hagander pushed:

Correctifs rejetés (à ce jour)

No one was disappointed this week :-)

Correctifs en attente

Simon Riggs sent in another revision of a patch to speed up 2PC.

Marisa Emerson sent in another revision of a patch to support BSD Authentication.

Elvis Pranskevichus sent in a patch to fix an issue with dumping domain constraints in pg_dump.

Michael Paquier and Fabien COELHO traded patches to extend pgbench expressions with functions.

Dilip Kumar sent in another revision of a patch to help make relation extension more scalable.

Etsuro Fujita sent in another revision of a patch to help make FDW DML pushdown more efficient.

SAWADA Masahiko sent in two more revisions of a patch to add a "frozen" bit to the visibility map.

Anastasia Lubennikova sent in two more revisions of a patch to implement covering unique indexes.

Amit Kapila sent in a patch to optimize parallelism code for launched workers usage.

Michael Paquier sent in a patch to remove the service-related code in pg_ctl for Cygwin.

Tom Lane sent in a patch to show what might be needed to fix PL/Python[23] issues in PostgreSQL 9.1. In view of 9.1's short remaining life, this is not going to be applied.

David Rowley sent in two more revisions of a patch to remove functionally dependent GROUP BY columns.

Filip Rembiałkowski sent in a patch to document the fact that BYPASSRLS is a CREATE USER option.

Andres Freund sent in a patch to allow to easily choose between the readiness primitives in unix_latch.c, error out if waiting on socket readiness without a specified socket, only clear unix_latch.c's self-pipe if it actually contains data, and support using epoll as the polling primitive in unix_latch.c.

Amit Langote sent in a patch to fix a comment thinko in expand_inherited_rtentry().

Vinayak Pokale sent in a patch to fix a typo in sequence.c.

Tatsuro Yamada sent in a patch to fix a comment typo in port/atomics/generic.h.

David Rowley sent in two more revisions of a patch to implement combining aggregates.

Mithun C Y sent in a patch to cache snapshot data avoid cuncurrent write to cache.

Etsuro Fujita sent in another revision of a patch to create foreign scan plan.

Etsuro Fujita sent in a patch to update a comment in setrefs.c.

Etsuro Fujita sent in a patch to make a minor documentation tweak to GetForeignPlan documentation.

Alexander Shulgin sent in a POC patch to create pg_logical_slot_stream_relation.

Christian Ullrich sent in another revision of a patch to fix an error in SSPI auth that could cause the wrong realm name to be used.

Jeff Janes sent in another revision of a patch to expose the GIN clean pending list to SQL.

Constantin S. Pan sent in a patch to speed up GIN build with parallel workers.

Andreas Seltenreich sent in a patch to improve spinlock inline assembly for x86.

José Arthur Benetasso Villanova sent in a patch to log operating system user connecting via unix socket.

Dean Rasheed sent in another revision of a patch to implement trigonometric functions in degrees.