Correctifs appliqués

Tom Lane a poussé :

  • Make psql's \d+ show reloptions for all relkinds. Formerly it would only show them for relkinds 'r' and 'f' (plain tables and foreign tables). However, as of 9.2, views can also have reloptions, namely security_barrier. The relkind restriction seems pointless and not at all future-proof, so just print reloptions whenever there are any. In passing, make some cosmetic improvements to the code that pulls the "tableinfo" fields out of the PGresult. Noted and patched by Dean Rasheed, with adjustment for all relkinds by me. http://git.postgresql.org/pg/commitdiff/c1f3c045cdc97fc74e571d4e8705f7dbe7e1ec8b
  • Fix pg_upgrade to cope with non-default unix_socket_directory scenarios. When starting either an old or new postmaster, force it to place its Unix socket in the current directory. This makes it even harder for accidental connections to occur during pg_upgrade, and also works around some scenarios where the default socket location isn't usable. (For example, if the default location is something other than "/tmp", it might not exist during "make check".) When checking an already-running old postmaster, find out its actual socket directory location from postmaster.pid, if possible. This dodges problems with an old postmaster having a configured location different from the default built into pg_upgrade's libpq. We can't find that out if the old postmaster is pre-9.1, so also document how to cope with such scenarios manually. In support of this, centralize handling of the connection-related command line options passed to pg_upgrade's subsidiary programs, such as pg_dump. This should make future changes easier. Bruce Momjian and Tom Lane http://git.postgresql.org/pg/commitdiff/f763b77193b04eba03a1f4ce46df34dc0348419e
  • Back-patch recent pg_upgrade fixes into 9.2. This syncs contrib/pg_upgrade in the 9.2 branch with HEAD, except for the HEAD changes related to converting XLogRecPtr to 64-bit int. It includes back-patching these commits: 666d494d19dbd5dc7a177709a2f7069913f8ab89 pg_upgrade: abstract out copying of files from old cluster to new 7afa8bed65ea925208f128048f3a528a64e1319a pg_upgrade: Run the created scripts in the test suite ab577e63faf792593ca728625a8ef0b1dfaf7500 Remove analyze_new_cluster.sh on make clean, too 34c02044ed7e7defde5a853b26dcd806c872d974 Fix thinko in comment 088c065ce8e405fafbfa966937184ece9defcf20 pg_upgrade: Fix exec_prog API to be less flaky f763b77193b04eba03a1f4ce46df34dc0348419e Fix pg_upgrade to cope with non-default unix_socket_directory scenarios. http://git.postgresql.org/pg/commitdiff/5c7e91e9c3d6716641ba52286c6d3daa6b1c13c0
  • Replace memcpy() calls in xlog.c critical sections with struct assignments. This gets rid of a dangerous-looking use of the not-volatile XLogCtl pointer in a couple of spinlock-protected sections, where the normal coding rule is that you should only access shared memory through a pointer-to-volatile. I think the risk is only hypothetical not actual, since for there to be a bug the compiler would have to move the spinlock acquire or release across the memcpy() call, which one sincerely hopes it will not. Still, it looks cleaner this way. Per comment from Daniel Farina and subsequent discussion. http://git.postgresql.org/pg/commitdiff/2a2352e07df9ccc70689061b6453e226a56e7c79
  • Fix PARAM_EXEC assignment mechanism to be safe in the presence of WITH. The planner previously assumed that parameter Vars having the same absolute query level, varno, and varattno could safely be assigned the same runtime PARAM_EXEC slot, even though they might be different Vars appearing in different subqueries. This was (probably) safe before the introduction of CTEs, but the lazy-evalution mechanism used for CTEs means that a CTE can be executed during execution of some other subquery, causing the lifespan of Params at the same syntactic nesting level as the CTE to overlap with use of the same slots inside the CTE. In 9.1 we created additional hazards by using the same parameter-assignment technology for nestloop inner scan parameters, but it was broken before that, as illustrated by the added regression test. To fix, restructure the planner's management of PlannerParamItems so that items having different semantic lifespans are kept rigorously separated. This will probably result in complex queries using more runtime PARAM_EXEC slots than before, but the slots are cheap enough that this hardly matters. Also, stop generating PlannerParamItems containing Params for subquery outputs: all we really need to do is reserve the PARAM_EXEC slot number, and that now only takes incrementing a counter. The planning code is simpler and probably faster than before, as well as being more correct. Per report from Vik Reykja. These changes will mostly also need to be made in the back branches, but I'm going to hold off on that until after 9.2.0 wraps. http://git.postgresql.org/pg/commitdiff/46c508fbcf98ac334f1e831d21021d731c882fbb
  • Silence -Wunused-result warning in contrib/pg_upgrade. This is just neatnik-ism, but since we do it for comparable code in elog.c, we may as well do it here. http://git.postgresql.org/pg/commitdiff/b98fd52a5516365e4a90d523cfed906eb7b3e67a
  • Restore SIGFPE handler after initializing PL/Perl. Perl, for some unaccountable reason, believes it's a good idea to reset SIGFPE handling to SIG_IGN. Which wouldn't be a good idea even if it worked; but on some platforms (Linux at least) it doesn't work at all, instead resulting in forced process termination if the signal occurs. Given the lack of other complaints, it seems safe to assume that Perl never actually provokes SIGFPE and so there is no value in the setting anyway. Hence, reset it to our normal handler after initializing Perl. Report, analysis and patch by Andres Freund. http://git.postgresql.org/pg/commitdiff/28ab4a5aabeec1db7e9d6fd14c26cc92ccb670a2
  • Make one last copy-editing pass over the 9.2 release notes. Also, set the release date to 2012-09-10, since we're pretty well committed to that now. http://git.postgresql.org/pg/commitdiff/185b744ee6115537e005b3d0d5e642c2146a12c1
  • Fix inappropriate error messages for Hot Standby misconfiguration errors. Give the correct name of the GUC parameter being complained of. Also, emit a more suitable SQLSTATE (INVALID_PARAMETER_VALUE, not the default INTERNAL_ERROR). Gurjeet Singh, errcode adjustment by me http://git.postgresql.org/pg/commitdiff/2e0cc1f031387fc304d11e55df0f9566d91698ff
  • Fix typo in information_schema documentation. Shigeru Hanada http://git.postgresql.org/pg/commitdiff/25f4fe4e461072a0371dc6d6cedbf08a04477fcd
  • Allow embedded spaces without quoting in unix_socket_directories entries. This fix removes an unnecessary incompatibility with the old behavior of the unix_socket_directory parameter. Since pathnames with embedded spaces are fairly popular on some platforms, the incompatibility could be significant in practice. We'll still strip unquoted leading/trailing spaces, however. No docs update since the documentation already implied that it worked like this. Per bug #7514 from Murray Cumming. http://git.postgresql.org/pg/commitdiff/d2286a98ef3fb88bafb57381b4c20b8b878827f1
  • Stamp 9.2.0. http://git.postgresql.org/pg/commitdiff/ef47adb414e46099155c34529a2a5caeea02fc41
  • Centralize libpq's low-level code for dropping a connection. Create an internal function pqDropConnection that does the physical socket close and cleans up closely-associated state. This removes a bunch of ad hoc, not always consistent closure code. The ulterior motive is to have a single place to wait for a spawned child backend to exit, but this seems like good cleanup even if that never happens. I went back and forth on whether to include "conn->status = CONNECTION_BAD" in pqDropConnection's actions, but for the moment decided not to. Only a minority of the call sites actually want that, and in any case it's arguable that conn->status is slightly higher-level state, and thus not part of this function's purview. http://git.postgresql.org/pg/commitdiff/210eb9b743c0645df05e5c8be4490ba4f09fc871
  • Fix PARAM_EXEC assignment mechanism to be safe in the presence of WITH. The planner previously assumed that parameter Vars having the same absolute query level, varno, and varattno could safely be assigned the same runtime PARAM_EXEC slot, even though they might be different Vars appearing in different subqueries. This was (probably) safe before the introduction of CTEs, but the lazy-evalution mechanism used for CTEs means that a CTE can be executed during execution of some other subquery, causing the lifespan of Params at the same syntactic nesting level as the CTE to overlap with use of the same slots inside the CTE. In 9.1 we created additional hazards by using the same parameter-assignment technology for nestloop inner scan parameters, but it was broken before that, as illustrated by the added regression test. To fix, restructure the planner's management of PlannerParamItems so that items having different semantic lifespans are kept rigorously separated. This will probably result in complex queries using more runtime PARAM_EXEC slots than before, but the slots are cheap enough that this hardly matters. Also, stop generating PlannerParamItems containing Params for subquery outputs: all we really need to do is reserve the PARAM_EXEC slot number, and that now only takes incrementing a counter. The planning code is simpler and probably faster than before, as well as being more correct. Per report from Vik Reykja. Back-patch of commit 46c508fbcf98ac334f1e831d21021d731c882fbb into all branches that support WITH. http://git.postgresql.org/pg/commitdiff/6c8656409bdded1d549bcd544a1c5c5e99701351
  • Adjust PL/Python regression tests some more for Python 3.3. Commit 2cfb1c6f77734db81b6e74bcae630f93b94f69be fixed some issues caused by Python 3.3 choosing to iterate through dict entries in a different order than before. But here's another one: the test cases adjusted here made two bad entries in a dict and expected the one complained of would always be the same. Possibly this should be back-patched further than 9.2, but there seems little point unless the earlier fix is too. http://git.postgresql.org/pg/commitdiff/45d1f1e024f99152fd0d06c62d0650f9ada33d5a
  • Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug. Investigation shows that some intermittent build failures in ecpg are the result of a gmake bug that was reported quite some time ago: http://savannah.gnu.org/bugs/?30653 Preventing parallel builds of the ecpg subdirectories seems to dodge the bug. Per yesterday's pgsql-hackers discussion, there are some other things in the subdirectory makefiles that seem rather unsafe for parallel builds too, but there's little point in fixing them as long as we have to work around a make bug. Back-patch to 9.1; parallel builds weren't very well supported before that anyway. http://git.postgresql.org/pg/commitdiff/843363b8d59e685b57a2f88c864a7041d44ffc06
  • Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches. http://git.postgresql.org/pg/commitdiff/59f23fe8d4eb0b95f029eaffdbcadc59d51f45cc

Andrew Dunstan a poussé :

Bruce Momjian a poussé :

Magnus Hagander a poussé :

Kevin Grittner a poussé :

  • Allow isolation tests to specify multiple setup blocks. Each setup block is run as a single PQexec submission, and some statements such as VACUUM cannot be combined with others in such a block. Backpatch to 9.2. Kevin Grittner and Tom Lane http://git.postgresql.org/pg/commitdiff/c63f309cca07c0570494a8f36092633635990db8
  • Fix serializable mode with index-only scans. Serializable Snapshot Isolation used for serializable transactions depends on acquiring SIRead locks on all heap relation tuples which are used to generate the query result, so that a later delete or update of any of the tuples can flag a read-write conflict between transactions. This is normally handled in heapam.c, with tuple level locking. Since an index-only scan avoids heap access in many cases, building the result from the index tuple, the necessary predicate locks were not being acquired for all tuples in an index-only scan. To prevent problems with tuple IDs which are vacuumed and re-used while the transaction still matters, the xmin of the tuple is part of the tag for the tuple lock. Since xmin is not available to the index-only scan for result rows generated from the index tuples, it is not possible to acquire a tuple-level predicate lock in such cases, in spite of having the tid. If we went to the heap to get the xmin value, it would no longer be an index-only scan. Rather than prohibit index-only scans under serializable transaction isolation, we acquire an SIRead lock on the page containing the tuple, when it was not necessary to visit the heap for other reasons. Backpatch to 9.2. Kevin Grittner and Tom Lane http://git.postgresql.org/pg/commitdiff/cdf91edba9f92306b49afcc6bfa6be0e56eb0688

Heikki Linnakangas a poussé :

  • Fix bugs in cascading replication with recovery_target_timeline='latest' The cascading replication code assumed that the current RecoveryTargetTLI never changes, but that's not true with recovery_target_timeline='latest'. The obvious upshot of that is that RecoveryTargetTLI in shared memory needs to be protected by a lock. A less obvious consequence is that when a cascading standby is connected, and the standby switches to a new target timeline after scanning the archive, it will continue to stream WAL to the cascading standby, but from a wrong file, ie. the file of the previous timeline. For example, if the standby is currently streaming from the middle of file 000000010000000000000005, and the timeline changes, the standby will continue to stream from that file. However, the WAL on the new timeline is in file 000000020000000000000005, so the standby sends garbage from 000000010000000000000005 to the cascading standby, instead of the correct WAL from file 000000020000000000000005. This also fixes a related bug where a partial WAL segment is restored from the archive and streamed to a cascading standby. The code assumed that when a WAL segment is copied from the archive, it can immediately be fully streamed to a cascading standby. However, if the segment is only partially filled, ie. has the right size, but only N first bytes contain valid WAL, that's not safe. That can happen if a partial WAL segment is manually copied to the archive, or if a partial WAL segment is archived because a server is started up on a new timeline within that segment. The cascading standby will get confused if the WAL it received is not valid, and will get stuck until it's restarted. This patch fixes that problem by not allowing WAL restored from the archive to be streamed to a cascading standby until it's been replayed, and thus validated. http://git.postgresql.org/pg/commitdiff/c4c227477bfe91ff4dabfe310d1f69cf7a05e939
  • Fix compiler warnings about unused variables, caused by my previous commit. Reported by Peter Eisentraut. http://git.postgresql.org/pg/commitdiff/358ff99d70a7e75d5a95d1d83676fcdd193c845d
  • Fix WAL file replacement during cascading replication on Windows. When the startup process restores a WAL file from the archive, it deletes any old file with the same name and renames the new file in its place. On Windows, however, when a file is deleted, it still lingers as long as a process holds a file handle open on it. With cascading replication, a walsender process can hold the old file open, so the rename() in the startup process would fail. To fix that, rename the old file to a temporary name, to make the original file name available for reuse, before deleting the old file. http://git.postgresql.org/pg/commitdiff/ab9a14e903347929d248ac4dabe2614de482350b

Alvaro Herrera a poussé :

Robert Haas a poussé :

Peter Eisentraut a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Sergey Konoplev sent in an instruction set for connecting extant replicas to a new master.
  • KaiGai Kohei sent in two more revisions of the patch to add row-level access control.
  • Amit Kapila sent in three more revisions of a patch to improve performance in buffer management.
  • Alexander Korotkov sent in another revision of the patch to improve statistics and selectivity estimates for ranges.
  • Alexander Korotkov sent in another revision of the patch to add SP-GiST for ranges based on 2d-mapping and quad-tree.
  • Alexander Korotkov sent in another revisionof the patch to remove some bloat issues from gistchoose.
  • Alvaro Herrera sent in another revision of the patch to add embedded lists in performance-critical places in the code.
  • Tom Lane sent in two more revisions of a patch to allow having a stand-alone backend which supports the full FE/BE protocol.
  • Pavel Stehule sent in a patch to disable bypassing of parameters for variadic function with "ANY" type variadic parameter.
  • Andrew Dunstan sent in a patch to enable pg_upgrade testing for MSVC builds.
  • Peter Geoghegan sent in a patch to add the average sync time per op to the output produced by pg_test_fsync.
  • Tom Lane and Peter Eisentraut sent in patches to improve building PL/Python 2 and 3 better: Tom's specific to the PL/Python cases, Peter's to allow multiple shared libraries per directory, which could fix other cases.
  • KaiGai Kohei sent in three patches all in service of coordinating how ALTER commands are implemented.