== PostgreSQL Weekly News - September 10 2012 == - Mailing list pgsql-announce
| From | David Fetter |
|---|---|
| Subject | == PostgreSQL Weekly News - September 10 2012 == |
| Date | |
| Msg-id | 20120910160330.GB12290@fetter.org Whole thread Raw |
| List | pgsql-announce |
== PostgreSQL Weekly News - September 10 2012 == PostgreSQL 9.2.0 released. You can go to production now! http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.2 The schedule for PGConf.EU 2012 in Prague October 23-26 is up at http://2012.pgconf.eu/schedule/ == PostgreSQL Product News == Npgsql2 2.0.12, a .NET connector for PostgreSQL, released. http://www.npgsql.org pgBadger 2.0, a PostgreSQL log analyzer written in Perl, released: http://dalibo.github.com/pgbadger/ Database Master 5, a GUI-based administration and development environment with support for PostgreSQL, released. http://www.nucleonsoftware.com/Products/Database-Master Postgres-XC 1.0.1, a write-scalable multi-master symmetric cluster based on PostgreSQL, released. http://postgres-xc.sourceforge.net/docs/1_0/release-xc-1-0-1.html == PostgreSQL Jobs for September == http://archives.postgresql.org/pgsql-jobs/2012-09/threads.php == PostgreSQL Local == Philly PUG will have its first meeting Sept 12, 2012. Bruce Momjian presents: What's new in PostgreSQL 9.2. Details and R, SVP, below. http://www.phlpug.org/events/78529522/ PostgreSQL Session will be held on October 4th, 2012, in Paris, France. More information at: http://www.postgresql-sessions.org/en/4/ PostgreSQL Conference Europe 2012 will be in Prague, Czech Republic on October 23-26. http://2012.pgconf.eu/ PostgreSQL Day Argentina 2012 will be held on November 13th in Bernal, Buenos Aires, at the National University of Quilmes. It will cover topics for PostgreSQL users, developers and contributors, as well as decision and policy makers. For more information about the conference, please see the website at http://www.pgday.com.ar/quilmes2012?lang=en This year Ecuador's PGDay will be held at Quito city on November 17th, 2012. The Call for Papers is open until October 10. Send proposals to Jaime Casanova jaime <AT> 2ndquadrant <DOT> com. The sixth edition of the Italian PostgreSQL Day (PGDay.IT 2012) will be held on November 23, 2012 in Prato, Tuscany. The International Call for Papers is now open. Talks and presentations in English are accepted. Information in English for papers submission is available at: http://2012.pgday.it/call-for-papers/international-call-for-papers/ == PostgreSQL in the News == Planet PostgreSQL: http://planet.postgresql.org/ PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm Pacific time. Please send English language ones to david@fetter.org, German language to pwn@pgug.de, Italian language to pwn@itpug.org. Spanish language to pwn@arpug.com.ar. == Applied Patches == Tom Lane pushed: - 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 pushed: - Fix bugs in exec.c that prevented pg_upgrade working in Windows. Backpatch to 9.2 - code before that is quite different and should not have these defects. http://git.postgresql.org/pg/commitdiff/6259678f8f5443e9d396e20418448b247c6948dd - Use correct path separator for Windows builtin commands. pg_upgrade produces a platform-specific script to remove the old directory, but on Windows it has not been making sure that the paths it writes as arguments for rmdir and del use the backslash path separator, which will cause these scripts to fail. The fix is backpatched to Release 9.0. http://git.postgresql.org/pg/commitdiff/504aeea6926730f6fa9d3e0ec3a181b659c2f594 - Allow pg_upgrade "make check" to run on Windows/MSys. Backpatch to 9.2. http://git.postgresql.org/pg/commitdiff/e442b0f0c6fd26738bafdeb5222511b586dfe4b9 - Unbreak Windows builds on 9.0 broken by 4397c51816cbb918fc3aebc474dd53bc231502b9. http://git.postgresql.org/pg/commitdiff/e62ad18663f0fcc37f9b4628bd244398b61aee67 - Indent fix_path_separator() header properly. http://git.postgresql.org/pg/commitdiff/2f0c7d585412e0c061cb1cd8c2c0a4b6aada4f74 - Fix command echoing in pg_upgade's analyze script for Windows. http://git.postgresql.org/pg/commitdiff/0829c7087e170a49d2cd3a15621c5c50fb5897fc - Fix transcription error. http://git.postgresql.org/pg/commitdiff/2042185baf91187c8761e99ff7955bd8e52ec028 - Fix line end mishandling in pg_upgrade on Windows. pg_upgrade opened the output from pg_dumpall in text mode and wrote the split files in text mode. This caused unwanted eating of intended carriage returns on input and production of spurious carriage returns on output. To avoid this, open all these files in binary mode. On non-Windows platforms, this change has no effect. Backpatch to 9.0. On 9.0 and 9.1, we also switch from redirecting pg_dumpall's output to using pg_dumpall's -f switch, for the same reason. http://git.postgresql.org/pg/commitdiff/ea0b414a0d9caaad1b7f39acd57708895c4dd0f3 - Fix pg_upgrade test script's line end handling on Windows. Call pg_dumpall using -f switch instead of redirection, to avoid writing the output in text mode and generating spurious carriage returns. Remove to carriage return ignoring hack introduced by commit e442b0f0c6fd26738bafdeb5222511b586dfe4b9. Backpatch to 9.2. http://git.postgresql.org/pg/commitdiff/f8f5cf33a30a2f6eeeb839ce92cb6ee04b518c5a - In pg_upgrade, try a few times to open a log file. If we call pg_ctl stop, the server might continue and thus hold a log file for a short time after it has deleted its pid file, (which is when pg_ctl will exit), and so a subsequent attempt to open the log file might fail. We therefore try to open it a few times, sleeping one second between tries, to give the server time to exit. This corrects an error that was observed on the buildfarm. Backpatched to 9.2, http://git.postgresql.org/pg/commitdiff/f8c81c5dde23a0be553e95728ffc11e76602fd24 Bruce Momjian pushed: - In pg_upgrade, pull the port number from postmaster.pid, like we do for socket location. Also, prevent putting the socket in the current directory for pre-9.1 servers in live check and non-live check mode, because pre-9.1 pg_ctl -w can't handle it. Backpatch to 9.2. http://git.postgresql.org/pg/commitdiff/a80b8037cfc24a4fa75ba267b6d39cba105ad4d6 - Fix to_date() and to_timestamp() to allow specification of the day of the week via ISO or Gregorian designations. The fix is to store the day-of-week consistently as 1-7, Sunday = 1. Fixes bug reported by Marc Munro http://git.postgresql.org/pg/commitdiff/015722fb364416b29fb1bb2c10631feb67ad61cd - Document that pg_upgrade requires PGHOST be set for any pre-9.1 servers with a socket directory mismatch with the new server. Backpatch to 9.2. http://git.postgresql.org/pg/commitdiff/00a8eb61a254f620dbf4ba5de2f33831f159cdeb - Remove src/tool/backend, now that the content is on the web site and wiki. http://git.postgresql.org/pg/commitdiff/63f1ccd838a19e4a0923221b2f90e4e014cabf74 - In pg_upgrade, document why we can't issue \n\n in the command logfile on Windows. Slightly cleanup log output on Windows given this restriction. Backpatch to 9.2. http://git.postgresql.org/pg/commitdiff/022cd22f0fa39f3446b7aa31a72170f160e1a905 Magnus Hagander pushed: - Remove some useless trailing whitespace. Michael Paquier http://git.postgresql.org/pg/commitdiff/bd46b5219940be1801720fc7e760e4b4bcaef286 - Mention basebackup-from-slave next to cascading replication http://git.postgresql.org/pg/commitdiff/4effe7a589972d8cbd39529e2ea83b712b12ba6f - Change "restoring" to "processing" in message from pg_dump. The same message is used in both pg_restore and pg_dump, and it's confusing to output "restoring data for table xyz" when the user is just doing a pg_dump. http://git.postgresql.org/pg/commitdiff/d074805fd42d077e850d69ca46fafc0dddf42671 Kevin Grittner pushed: - 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 pushed: - 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 pushed: - Trim spgist_private.h inclusion. It doesn't really need rel.h; relcache.h is enough. http://git.postgresql.org/pg/commitdiff/e20a90e1887152f1e0c149a02c50d6bafb2596e5 Robert Haas pushed: - sepgsql cleanups. This is needed to match recent changes elsewhere. Along the way, some renaming for clarity. KaiGai Kohei http://git.postgresql.org/pg/commitdiff/aa2b237ce51ef12c213ac55d4d3aba509cb3133e - Fix "too many arguments" messages not to index off the end of argv[]. This affects initdb, clusterdb, reindexdb, and vacuumdb in master and 9.2; in earlier branches, only initdb is affected. http://git.postgresql.org/pg/commitdiff/0a1967a0ef01cd193d9aa212dcf54a1b1d56720e - Update syntax shown for \copy to match new syntax for COPY. Etsuro Fujita http://git.postgresql.org/pg/commitdiff/dda589c96b89320446933108ca946e7e6b8eb9d2 Peter Eisentraut pushed: - pgbench: Show better progress when loading tuples. Show target number of tuples and percentage in addition to current number. http://git.postgresql.org/pg/commitdiff/4c60b80094009c6f8ed9ccee365e445f07e609ab - Translation updates http://git.postgresql.org/pg/commitdiff/1bc414ca7642bf32be80fcbe4760fca0307d2e12 == Rejected Patches (for now) == No one was disappointed this week :-) == Pending Patches == 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.
pgsql-announce by date: