La PGConf.DE se tiendra à Hamburg (Allemagne) les 26 et 27 novembre au Lindner Hotel am Michel. L'appel à conférenciers court jusqu'au 13 septembre 2015 : http://2015.pgconf.de/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en juin

PostgreSQL Local

PostgreSQL dans les média

PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA. La version originale se trouve à l'adresse suivante : http://www.postgresql.org/message-id/20150628215355.GB30019@fetter.org

Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.

Correctifs appliqués

Noah Misch pushed:

  • Truncate strings in tarCreateHeader() with strlcpy(), not sprintf(). This supplements the GNU libc bug #6530 workarounds introduced in commit 54cd4f04576833abc394e131288bf3dd7dcf4806. On affected systems, a tar-format pg_basebackup failed when some filename beneath the data directory was not valid character data in the postmaster/walsender locale. Back-patch to 9.1, where pg_basebackup was introduced. Extant, bug-prone conversion specifications receive only ASCII bytes or involve low-importance messages. http://git.postgresql.org/pg/commitdiff/4318118edd5582696027f357771e0a8b091fe2bf

Robert Haas pushed:

Tom Lane pushed:

  • Improve inheritance_planner()'s performance for large inheritance sets. Commit c03ad5602f529787968fa3201b35c119bbc6d782 introduced a planner performance regression for UPDATE/DELETE on large inheritance sets. It required copying the append_rel_list (which is of size proportional to the number of inherited tables) once for each inherited table, thus resulting in O(N^2) time and memory consumption. While it's difficult to avoid that in general, the extra work only has to be done for append_rel_list entries that actually reference subquery RTEs, which inheritance-set entries will not. So we can buy back essentially all of the loss in cases without subqueries in FROM; and even for those, the added work is mainly proportional to the number of UNION ALL subqueries. Back-patch to 9.2, like the previous commit. Tom Lane and Dean Rasheed, per a complaint from Thomas Munro. http://git.postgresql.org/pg/commitdiff/2cb9ec1bcb35dd6b4cf7a4a325aaa9791444e69d
  • Docs: fix claim that to_char('FM') removes trailing zeroes. Of course, what it removes is leading zeroes. Seems to have been a thinko in commit ffe92d15d53625d5ae0c23f4e1984ed43614a33d. Noted by Hubert Depesz Lubaczewski. http://git.postgresql.org/pg/commitdiff/d759b7eb6aee12bd52516905d790072845b4356f
  • Fix the logic for putting relations into the relcache init file. Commit f3b5565dd4e59576be4c772da364704863e6a835 was a couple of bricks shy of a load; specifically, it missed putting pg_trigger_tgrelid_tgname_index into the relcache init file, because that index is not used by any syscache. However, we have historically nailed that index into cache for performance reasons. The upshot was that load_relcache_init_file always decided that the init file was busted and silently ignored it, resulting in a significant hit to backend startup speed. To fix, reinstantiate RelationIdIsInInitFile() as a wrapper around RelationSupportsSysCache(), which can know about additional relations that should be in the init file despite being unknown to syscache.c. Also install some guards against future mistakes of this type: make write_relcache_init_file Assert that all nailed relations get written to the init file, and make load_relcache_init_file emit a WARNING if it takes the "wrong number of nailed relations" exit path. Now that we remove the init files during postmaster startup, that case should never occur in the field, even if we are starting a minor-version update that added or removed rels from the nailed set. So the warning shouldn't ever be seen by end users, but it will show up in the regression tests if somebody breaks this logic. Back-patch to all supported branches, like the previous commit. http://git.postgresql.org/pg/commitdiff/5d1ff6bd559ea8df1b7302e245e690b01b9a4fa4
  • Avoid passing NULL to memcmp() in lookups of zero-argument functions. A few places assumed they could pass NULL for the argtypes array when looking up functions known to have zero arguments. At first glance it seems that this should be safe enough, since memcmp() is surely not allowed to fetch any bytes if its count argument is zero. However, close reading of the C standard says that such calls have undefined behavior, so we'd probably best avoid it. Since the number of places doing this is quite small, and some other places looking up zero-argument functions were already passing dummy arrays, let's standardize on the latter solution rather than hacking the function lookup code to avoid calling memcmp() in these cases. I also added Asserts to catch any future violations of the new rule. Given the utter lack of any evidence that this actually causes any problems in the field, I don't feel a need to back-patch this change. Per report from Piotr Stefaniak, though this is not his patch. http://git.postgresql.org/pg/commitdiff/0a52d378b03b7d5ab1d64627a87edaf5ed311c6c

Peter Eisentraut pushed:

Heikki Linnakangas pushed:

  • Add missing newline to debug-message. Michael Paquier http://git.postgresql.org/pg/commitdiff/9cb36981fbbf2f298db2476101f4475c52d00fbb
  • Fix a couple of bugs with wal_log_hints. 1. Replay of the WAL record for setting a bit in the visibility map contained an assertion that a full-page image of that record type can only occur with checksums enabled. But it can also happen with wal_log_hints, so remove the assertion. Unlike checksums, wal_log_hints can be changed on the fly, so it would be complicated to figure out if it was enabled at the time that the WAL record was generated. 2. wal_log_hints has the same effect on the locking needed to read the LSN of a page as data checksums. BufferGetLSNAtomic() didn't get the memo. Backpatch to 9.4, where wal_log_hints was added. http://git.postgresql.org/pg/commitdiff/4b8e24b9ad308c30dbe2184e06848e638e018114
  • Fix typo in comment. Etsuro Fujita http://git.postgresql.org/pg/commitdiff/7845db2aa778aa751b41cff72c41c94993e975e3
  • Add missing_ok option to the SQL functions for reading files. This makes it possible to use the functions without getting errors, if there is a chance that the file might be removed or renamed concurrently. pg_rewind needs to do just that, although this could be useful for other purposes too. (The changes to pg_rewind to use these functions will come in a separate commit.) The read_binary_file() function isn't very well-suited for extensions.c's purposes anymore, if it ever was. So bite the bullet and make a copy of it in extension.c, tailored for that use case. This seems better than the accidental code reuse, even if it's a some more lines of code. Michael Paquier, with plenty of kibitzing by me. http://git.postgresql.org/pg/commitdiff/cb2acb1081e13b4b27a76c6b5311115528e49c59
  • Don't choke on files that are removed while pg_rewind runs. If a file is removed from the source server, while pg_rewind is running, the invocation of pg_read_binary_file() will fail. Use the just-added missing_ok option to that function, to have it return NULL instead, and handle that gracefully. And similarly for pg_ls_dir and pg_stat_file. Reported by Fujii Masao, fix by Michael Paquier. http://git.postgresql.org/pg/commitdiff/b36805f3c54fe0e50e58bb9e6dad66daca46fbf6
  • Fix double-XLogBeginInsert call in GIN page splits. If data checksums or wal_log_hints is on, and a GIN page is split, the code to find a new, empty, block was called after having already called XLogBeginInsert(). That causes an assertion failure or PANIC, if finding the new block involves updating a FSM page that had not been modified since last checkpoint, because that update is WAL-logged, which calls XLogBeginInsert again. Nested XLogBeginInsert calls are not supported. To fix, rearrange GIN code so that XLogBeginInsert is called later, after finding the victim buffers. Reported by Jeff Janes. http://git.postgresql.org/pg/commitdiff/a45c70acf35e43257d86313dcbb7bb0e5201fab1
  • Promote the assertion that XLogBeginInsert() is not called twice into ERROR. Seems like cheap insurance for WAL bugs. A spurious call to XLogBeginInsert() in itself would be fairly harmless, but if there is any data registered and the insertion is not completed/cancelled properly, there is a risk that the data ends up in a wrong WAL record. Per Jeff Janes's suggestion. http://git.postgresql.org/pg/commitdiff/a32c3ec893cafbd3a4b42c34270a80198f28f123
  • Fix markup in docs. Oops. I could swear I built the docs before pushing, but I guess not.. http://git.postgresql.org/pg/commitdiff/6ab4d38ab085b0177d7ce63f7e1f2fb3f3a8e4a5

Fujii Masao pushed:

Andres Freund pushed:

  • Fix the fallback memory barrier implementation to be reentrant. This was essentially "broken" since 0c8eda62; but until more recently (14e8803f) barriers usage in signal handlers was infrequent. The failure to be reentrant was noticed because the test_shm_mq, which uses memory barriers at a high frequency, occasionally got stuck on some solaris buildfarm animals. Turns out, those machines use sun studio 12.1, which doesn't yet have efficient memory barrier support. A machine with a newer sun studio did not fail. Forcing the barrier fallback to be used on x86 allows to reproduce the problem. The new fallback is to use kill(PostmasterPid, 0) based on the theory that that'll always imply a barrier due to checking the liveliness of PostmasterPid on systems old enough to need fallback support. It's hard to come up with a good and performant fallback. I'm not backpatching this for now - the problem isn't active in the back branches, and we haven't backpatched barrier changes for now. Additionally master looks entirely different than the back branches due to the new atomics abstraction. It seems better to let this rest in master, where the non-reentrancy actively causes a problem, and then consider backpatching. Found-By: Robert Haas Discussion: 55626265.3060800@dunslane.net http://git.postgresql.org/pg/commitdiff/1b468a131bd260c9041484f78b8580c7f232d580
  • Fix test_decoding's handling of nonexistant columns in old tuple versions. test_decoding used fastgetattr() to extract column values. That's wrong when decoding updates and deletes if a table's replica identity is set to FULL and new columns have been added since the old version of the tuple was created. Due to the lack of a crosscheck with the datum's natts values an invalid value will be output, leading to errors or worse. Bug: #13470 Reported-By: Krzysztof Kotlarski Discussion: 20150626100333.3874.90852@wrigleys.postgresql.org Backpatch to 9.4, where the feature, including the bug, was added. http://git.postgresql.org/pg/commitdiff/d47a1136e441cebe7ae7fe72d70eb8ce278d5cd6

Ãlvaro Herrera pushed:

Simon Riggs pushed:

Kevin Grittner pushed:

  • Add opaque declaration of HTAB to tqual.h. Commit b89e151054a05f0f6d356ca52e3b725dd0505e53 added the ResolveCminCmaxDuringDecoding declaration to tqual.h, which uses an HTAB parameter, without declaring HTAB. It accidentally fails to fail to build with current sources because a declaration happens to be included, directly or indirectly, in all source files that currently use tqual.h before tqual.h is first included, but we shouldn't count on that. Since an opaque declaration is enough here, just use that, as was done in snapmgr.h. Backpatch to 9.4, where the HTAB reference was added to tqual.h. http://git.postgresql.org/pg/commitdiff/604e99396de02f6f23950ee373c13335d2ccdf05
  • Fix comment for GetCurrentIntegerTimestamp(). The unit of measure is microseconds, not milliseconds. Backpatch to 9.3 where the function and its comment were added. http://git.postgresql.org/pg/commitdiff/cca8ba9529f8815acd23fe88c32763765d0e1b68

Tatsuo Ishii pushed:

Correctifs rejetés (à ce jour)

No one was disappointed this week :-)

Correctifs en attente

Peter Geoghegan sent in a patch to allow JSON[B] arrays to take negative subscripts.

Tomas Vondra sent in a patch to add density correction to sampling for statistics collection.

Michael Paquier sent in a patch to fix some white space in pg_rewind error messages.

Michael Paquier and Robert Haas traded patches to fix an issue where a dangerous rm -rf was being issued in the global makefile.

Michael Paquier sent in two more revisions of a patch to update the hash index creation warning.

Abhijit Menon-Sen sent in a patch to introduce XLogLockBlockRangeForCleanup().

Fabien COELHO sent in another revision of a patch to add checkpointer continuous flushing.

Michael Paquier sent in another revision of a patch to add support for TAP tests on Windows.

Michael Paquier sent in a patch to improve log capture of TAP tests and fix race conditions.

Fabrízio de Royes Mello sent in two more revisions of a patch to add CINE for ALTER TABLE ... ADD COLUMN.

Uriy Zhuravlev sent in another revision of a patch to implement ALTER OPERATOR.

Craig Ringer sent in a patch to implement ALTER TABLE ... ALTER CONSTRAINT ... SET DEFERRABLE on UNIQUE or PK.

Oskari Saarenmaa sent in a patch to add -lrt to configure for sched_yield on Solaris.

Jim Nasby sent in a patch to ensure that object_classes is properly sized.

Marco Nenciarini sent in a patch to fix an off-by-one bug which caused VACUUM FREEZE to mistakenly cancel standby sessions.

Peter Geoghegan sent in a patch to add some compatibility notes for UPSERT with foreign data wrappers.

Amit Kapila sent in a patch to improve the performance of DROP TABLE when the shared_buffers setting is high.

Jeff Janes sent in a patch to make pg_trgm perform better by supporting the triconsistent function, introduced in version 9.4 of the server, to make it faster to implement indexed queries where some keys are common and some are rare.

Tom Lane sent in a patch to refactor the way the pg_file_settings view works.