La date limite de l'appel à conférenciers pour le PgDay italien a été repoussée au 4 août 2013 : http://2013.pgday.it/index.php/programma/call-for-papers-english/

Offres d'emplois autour de PostgreSQL en juillet

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.

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.

(lien vers l'article original)

Correctifs appliqués

Robert Haas a poussé :

  • Add infrastructure for mapping relfilenodes to relation OIDs. Future patches are expected to introduce logical replication that works by decoding WAL. WAL contains relfilenodes rather than relation OIDs, so this infrastructure will be needed to find the relation OID based on WAL contents. If logical replication does not make it into this release, we probably should consider reverting this, since it will add some overhead to DDL operations that create new relations. One additional index insert per pg_class row is not a large overhead, but it's more than zero. Another way of meeting the needs of logical replication would be to the relation OID to WAL, but that would burden DML operations, not only DDL. Andres Freund, with some changes by me. Design review, in earlier versions, by Álvaro Herrera. http://git.postgresql.org/pg/commitdiff/f01d1ae3a104019d6d68aeff85c4816a275130b3
  • Adjust HeapTupleSatisfies* routines to take a HeapTuple. Previously, these functions took a HeapTupleHeader, but upcoming patches for logical replication will introduce new a new snapshot type under which the tuple's TID will be used to lookup (CMIN, CMAX) for visibility determination purposes. This makes that information available. Code churn is minimal since HeapTupleSatisfiesVisibility took the HeapTuple anyway, and deferenced it before calling the satisfies function. Independently of logical replication, this allows t_tableOid and t_self to be cross-checked via assertions in tqual.c. This seems like a useful way to make sure that all callers are setting these values properly, which has been previously put forward as desirable. Andres Freund, reviewed by Álvaro Herrera http://git.postgresql.org/pg/commitdiff/0518eceec3a1cc2b71da04e839f05f555fdd8567
  • Remove bgw_sighup and bgw_sigterm. Per discussion on pgsql-hackers, these aren't really needed. Interim versions of the background worker patch had the worker starting with signals already unblocked, which would have made this necessary. But the final version does not, so we don't really need it; and it doesn't work well with the new facility for starting dynamic background workers, so just rip it out. Also per discussion on pgsql-hackers, back-patch this change to 9.3. It's best to get the API break out of the way before we do an official release of this facility, to avoid more pain for extension authors later. http://git.postgresql.org/pg/commitdiff/f40a318eeaed0c66fcb2ddd442006e54bf49c634
  • pgrowlocks: Use GetActiveSnapshot() rather than SnapshotNow. Per discussion, it's desirable to eliminate all remaining uses of SnapshotNow, because it has unpleasant semantics: race conditions can result in seeing multiple versions of a concurrently updated row, or none at all. By using GetActiveSnapshot() here, callers will see exactly those rows that would have been visible if the invoking query had scanned the table using, for example, a SELECT statement. This is slightly different from the old behavior, because commits that happen concurrently with the scan will not affect the results. In REPEATABLE READ or SERIALIZABLE modes, where transaction snapshots are used, commits that have happened since the start of the transaction will also not affect the results. It is hoped that this minor incompatibility will be thought an improvement, or at least no worse than what we did before. http://git.postgresql.org/pg/commitdiff/2e44770fa39051f404f7d94fed557b359b1dba3c
  • Fix cache flush hazard in ExecRefreshMatView. Andres Freund http://git.postgresql.org/pg/commitdiff/21e28e4531e761e7cdf1b9a0bbf0c06f6107686a
  • Additional regression tests for ALTER OPERATOR FAMILY. Robins Tharakan, reviewed by Szymon Guz http://git.postgresql.org/pg/commitdiff/e6055061c524698918ab0b7a0c51b822c03ef1fa
  • Use InvalidSnapshot, now SnapshotNow, as the default snapshot. As far as I can determine, there's no code in the core distribution that fails to explicitly set the snapshot of a scan or executor state. If there is any such code, this will probably cause it to seg fault; friendlier suggestions were discussed on pgsql-hackers, but there was no consensus that anything more than this was needed. This is another step towards the hoped-for complete removal of SnapshotNow. http://git.postgresql.org/pg/commitdiff/765ad89be36f699e2d65238c1f0458a1ab7e4d8b
  • Don't use SnapshotNow in get_actual_variable_range. Instead, use the active snapshot. Per Tom Lane, this function is most interested in knowing the range of tuples our scan will actually see. This is another step towards full removal of SnapshotNow. http://git.postgresql.org/pg/commitdiff/3483f4332de73e038db64be0614219b64fd3c971
  • pgstattuple: Use SnapshotDirty, not SnapshotNow. Tuples belonging to uncommitted transactions should not be counted as dead. This is arguably a bug fix that should be back-patched, but as no one ever noticed until it came time to try to get rid of SnapshotNow, I'm only doing this in master for now. http://git.postgresql.org/pg/commitdiff/80c79ab2a8d63bc6c83269b29c1ba993c8077d3a
  • pgstattuple: Doc update for previous commit. In my previous change to make pgstattuple use SnapshotDirty rather than SnapshotNow, I failed to notice that the documenation also needed to be updated to match. Fix. http://git.postgresql.org/pg/commitdiff/fd27b999196959bd20d777a1010c786feb1586c2
  • Change currtid functions to use an MVCC snapshot, not SnapshotNow. This has a slight performance cost, but the only known consumers of these functions, known at the SQL level as currtid and currtid2, is pgsql-odbc; whose usage, we hope, is not sufficiently intensive to make this a problem. Per discussion. http://git.postgresql.org/pg/commitdiff/ed93feb80891b131e9676e962256cc2b18aa5e78

Alvaro Herrera a poussé :

Tatsuo Ishii a poussé :

Peter Eisentraut a poussé :

Tom Lane a poussé :

  • Change post-rewriter representation of dropped columns in joinaliasvars. It's possible to drop a column from an input table of a JOIN clause in a view, if that column is nowhere actually referenced in the view. But it will still be there in the JOIN clause's joinaliasvars list. We used to replace such entries with NULL Const nodes, which is handy for generation of RowExpr expansion of a whole-row reference to the view. The trouble with that is that it can't be distinguished from the situation after subquery pull-up of a constant subquery output expression below the JOIN. Instead, replace such joinaliasvars with null pointers (empty expression trees), which can't be confused with pulled-up expressions. expandRTE() still emits the old convention, though, for convenience of RowExpr generation and to reduce the risk of breaking extension code. In HEAD and 9.3, this patch also fixes a problem with some new code in ruleutils.c that was failing to cope with implicitly-casted joinaliasvars entries, as per recent report from Feike Steenbergen. That oversight was because of an inadequate description of the data structure in parsenodes.h, which I've now corrected. There were some pre-existing oversights of the same ilk elsewhere, which I believe are now all fixed. http://git.postgresql.org/pg/commitdiff/a7cd853b75d01666135ca87353cee83b99d06b9b
  • Further hacking on ruleutils' new column-alias-assignment code. After further thought about implicit coercions appearing in a joinaliasvars list, I realized that they represent an additional reason why we might need to reference the join output column directly instead of referencing an underlying column. Consider SELECT x FROM t1 LEFT JOIN t2 USING (x) where t1.x is of type date while t2.x is of type timestamptz. The merged output variable is of type timestamptz, but it won't go to null when t2 does, therefore neither t1.x nor t2.x is a valid substitute reference. The code in get_variable() actually gets this case right, since it knows it shouldn't look through a coercion, but we failed to ensure that the unqualified output column name would be globally unique. To fix, modify the code that trawls for a dangerous situation so that it actually scans through an unnamed join's joinaliasvars list to see if there are any non-simple-Var entries. http://git.postgresql.org/pg/commitdiff/ef655663c5069231e054c3514c3ee9b15b8a4f13
  • Move strip_implicit_coercions() from optimizer to nodeFuncs.c. Use of this function has spread into the parser and rewriter, so it seems like time to pull it out of the optimizer and put it into the more central nodeFuncs module. This eliminates the need to #include optimizer/clauses.h in most of the calling files, demonstrating that this function was indeed a bit outside the normal code reference patterns. http://git.postgresql.org/pg/commitdiff/10a509d82956dee14eb2011bd266cd3c728ae188
  • Fix booltestsel() for case where we have NULL stats but not MCV stats. In a boolean column that contains mostly nulls, ANALYZE might not find enough non-null values to populate the most-common-values stats, but it would still create a pg_statistic entry with stanullfrac set. The logic in booltestsel() for this situation did the wrong thing for "col IS NOT TRUE" and "col IS NOT FALSE" tests, forgetting that null values would satisfy these tests (so that the true selectivity would be close to one, not close to zero). Per bug #8274. Fix by Andrew Gierth, some comment-smithing by me. http://git.postgresql.org/pg/commitdiff/b32a25c3d5292c800c0468097b9a63e931a0af0f
  • Improve ilist.h's support for deletion of slist elements during iteration. Previously one had to use slist_delete(), implying an additional scan of the list, making this infrastructure considerably less efficient than traditional Lists when deletion of element(s) in a long list is needed. Modify the slist_foreach_modify() macro to support deleting the current element in O(1) time, by keeping a "prev" pointer in addition to "cur" and "next". Although this makes iteration with this macro a bit slower, no real harm is done, since in any scenario where you're not going to delete the current list element you might as well just use slist_foreach instead. Improve the comments about when to use each macro. Back-patch to 9.3 so that we'll have consistent semantics in all branches that provide ilist.h. Note this is an ABI break for callers of slist_foreach_modify(). Andres Freund and Tom Lane http://git.postgresql.org/pg/commitdiff/fa2fad3c06bfde03594ff38d53acdf9a60c56bb2
  • Fix configure probe for sys/ucred.h. The configure script's test for <sys/ucred.h> did not work on OpenBSD, because on that platform <sys/param.h> has to be included first. As a result, socket peer authentication was disabled on that platform. Problem introduced in commit be4585b1c27ac5dbdd0d61740d18f7ad9a00e268. Andres Freund, slightly simplified by me. http://git.postgresql.org/pg/commitdiff/1b09630fce1dfd4116eaaf154766a8a435168193
  • Prevent leakage of SPI tuple tables during subtransaction abort. plpgsql often just remembers SPI-result tuple tables in local variables, and has no mechanism for freeing them if an ereport(ERROR) causes an escape out of the execution function whose local variable it is. In the original coding, that wasn't a problem because the tuple table would be cleaned up when the function's SPI context went away during transaction abort. However, once plpgsql grew the ability to trap exceptions, repeated trapping of errors within a function could result in significant intra-function-call memory leakage, as illustrated in bug #8279 from Chad Wagner. We could fix this locally in plpgsql with a bunch of PG_TRY/PG_CATCH coding, but that would be tedious, probably slow, and prone to bugs of omission; moreover it would do nothing for similar risks elsewhere. What seems like a better plan is to make SPI itself responsible for freeing tuple tables at subtransaction abort. This patch attacks the problem that way, keeping a list of live tuple tables within each SPI function context. Currently, such freeing is automatic for tuple tables made within the failed subtransaction. We might later add a SPI call to mark a tuple table as not to be freed this way, allowing callers to opt out; but until someone exhibits a clear use-case for such behavior, it doesn't seem worth bothering. A very useful side-effect of this change is that SPI_freetuptable() can now defend itself against bad calls, such as duplicate free requests; this should make things more robust in many places. (In particular, this reduces the risks involved if a third-party extension contains now-redundant SPI_freetuptable() calls in error cleanup code.) Even though the leakage problem is of long standing, it seems imprudent to back-patch this into stable branches, since it does represent an API semantics change for SPI users. We'll patch this in 9.3, but live with the leakage in older branches. http://git.postgresql.org/pg/commitdiff/3d13623d75d3206c8f009353415043a191ebab39

Bruce Momjian a poussé :

Stephen Frost a poussé :

  • Improvements to GetErrorContextStack(). As GetErrorContextStack() borrowed setup and tear-down code from other places, it was less than clear that it must only be called as a top-level entry point into the error system and can't be called by an exception handler (unlike the rest of the error system, which is set up to be reentrant-safe). Being called from an exception handler is outside the charter of GetErrorContextStack(), so add a bit more protection against it, improve the comments addressing why we have to set up an errordata stack for this function at all, and add a few more regression tests. Lack of clarity pointed out by Tom Lane; all bugs are mine. http://git.postgresql.org/pg/commitdiff/9bd0feeba85fae411e01798d5a5d76b70333e38e
  • Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL. This adds the ability to get the call stack as a string from within a PL/PgSQL function, which can be handy for logging to a table, or to include in a useful message to an end-user. Pavel Stehule, reviewed by Rushabh Lathia and rather heavily whacked around by Stephen Frost. http://git.postgresql.org/pg/commitdiff/831283256796d1c20858862b568d73e505eb4a84

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Greg Smith sent in another revision of a patch to add --throttle to pgbench.
  • Karol Trzcionka sent in another revision of a patch to implement UPDATE ... RETURNING BEFORE/AFTER.
  • Satoshi Nagayasu sent in a PoC patch to add a newpgstattuple function to allow block sampling.
  • Alvaro Herrera sent in a patch to improve the error messages for row-level locks.
  • David Fetter sent in two more revisions of a patch to add ORDINALITY for set-returning functions.
  • Amit Kapila sent in another revision of a patch to implement ALTER SYSTEM.
  • Antonin Houska sent in a patch to allow throttling pg_basebackup.
  • Vik Fearing sent in a patch to fix a bug where the reported number of rows overflows the 32-bit integer assigned to it by making the integer 64-bit instead.
  • Robert Haas sent in another revision of a patch to add dynamic background workers.
  • Fabrízio de Royes Mello and Abhijit Menon-Sen traded patches to add IF NOT EXISTS to extant CREATE DDLs where it made sense and hadn't yet been implemented.
  • Ronan Dunklau sent in a patch to add "make coverage" targets for the additional supplied modules.
  • Robert Haas sent in another revision of a patch to remove SnapshotNow.
  • Andrew Dunstan sent in a patch to install libpq.dll in the bin directory on Windows when compiling under Cygwin.
  • Stephen Frost sent in a patch to