Correctifs appliqués

Peter Eisentraut a poussé :

Robert Haas a poussé :

Tom Lane a poussé :

  • Fix a couple of contrib/dblink bugs. dblink_exec leaked temporary database connections if any error occurred after connection setup, for example SELECT dblink_exec('...connect string...', 'select 1/0'); Add a PG_TRY block to ensure PQfinish gets done when it is needed. (dblink_record_internal is on the hairy edge of needing similar treatment, but seems not to be actively broken at the moment.) Also, in 9.0 and up, only one of the three functions using tuplestore return mode was properly checking that the query context would allow a tuplestore result. Noted while reviewing dblink patch. Back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/d843ed21164275dfbfefa486bb00bca91380cdf0
  • Fix syslogger to not lose log coherency under high load. The original coding of the syslogger had an arbitrary limit of 20 large messages concurrently in progress, after which it would just punt and dump message fragments to the output file separately. Our ambitions are a bit higher than that now, so allow the data structure to expand as necessary. Reported and patched by Andrew Dunstan; some editing by Tom http://git.postgresql.org/pg/commitdiff/c17e863bc7677a54d6da5bbb2868cca2cd9b30c1
  • Remove useless PGRES_COPY_BOTH "support" in psql. There is no existing or foreseeable case in which psql should see a PGRES_COPY_BOTH PQresultStatus; and if such a case ever emerges, it's a pretty good bet that these code fragments wouldn't do the right thing anyway. Remove them, and let the existing default cases do the appropriate thing, namely emit an "unexpected PQresultStatus" bleat. Noted while working on libpq row processor patch, for which I was considering adding a PGRES_SUSPENDED status code --- the same default-case treatment would be appropriate for that. http://git.postgresql.org/pg/commitdiff/cb917e1544612c187c74fed1a990e26820514c8a
  • Add a "row processor" API to libpq for better handling of large results. Traditionally libpq has collected an entire query result before passing it back to the application. That provides a simple and transactional API, but it's pretty inefficient for large result sets. This patch allows the application to process each row on-the-fly instead of accumulating the rows into the PGresult. Error recovery becomes a bit more complex, but often that tradeoff is well worth making. Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane http://git.postgresql.org/pg/commitdiff/92785dac2ee7026948962cd61c4cd84a2d052772
  • Improve efficiency of dblink by using libpq's new row processor API. This patch provides a test case for libpq's row processor API. contrib/dblink can deal with very large result sets by dumping them into a tuplestore (which can spill to disk) --- but until now, the intermediate storage of the query result in a PGresult meant memory bloat for any large result. Now we use a row processor to convert the data to tuple form and dump it directly into the tuplestore. A limitation is that this only works for plain dblink() queries, not dblink_send_query() followed by dblink_get_result(). In the latter case we don't know the desired tuple rowtype soon enough. While hack solutions to that are possible, a different user-level API would probably be a better answer. Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane http://git.postgresql.org/pg/commitdiff/6f922ef88e43b3084cdddf4b5ffe525a00896a90
  • Fix plpgsql named-cursor-parameter feature for variable name conflicts. The parser got confused if a cursor parameter had the same name as a plpgsql variable. Reported and diagnosed by Yeb Havinga, though this isn't exactly his proposed fix. Also, some mostly-but-not-entirely-cosmetic adjustments to the original named-cursor-parameter patch, for code readability and better error diagnostics. http://git.postgresql.org/pg/commitdiff/05dbd4a7734e09bd1f835f4197d9befa1c00c4f3
  • Update obsolete comment. Somebody didn't bother to fix this comment while adding foreign table support to the code below it. In passing, remove the explicit calling-out of relkind letters, which adds complexity to the comment but doesn't help in understanding the code. http://git.postgresql.org/pg/commitdiff/a75b08066ab4b426b1bd056fed81302e5a5d5371
  • Allow statistics to be collected for foreign tables. ANALYZE now accepts foreign tables and allows the table's FDW to control how the sample rows are collected. (But only manual ANALYZEs will touch foreign tables, for the moment, since among other things it's not very clear how to handle remote permissions checks in an auto-analyze.) contrib/file_fdw is extended to support this. Etsuro Fujita, reviewed by Shigeru Hanada, some further tweaking by me. http://git.postgresql.org/pg/commitdiff/263d9de66b867b7800fac82c222e004b795b724a
  • Dept of second thoughts: improve the API for AnalyzeForeignTable. If we make the initially-called function return the table physical-size estimate, acquire_inherited_sample_rows will be able to use that to allocate numbers of samples among child tables, when the day comes that we want to support foreign tables in inheritance trees. http://git.postgresql.org/pg/commitdiff/cea49fe82fedcf125eb99a780099eaf47a326b03
  • Fix broken comparetup_datum code. Commit 337b6f5ecf05b21b5e997986884d097d60e4e3d0 contained the entirely fanciful assumption that it had made comparetup_datum unreachable. Reported and patched by Takashi Yamamoto. Fix up some not terribly accurate/useful comments from that commit, too. http://git.postgresql.org/pg/commitdiff/17b985b1a068e120feb05bb61be6328f4fef8090
  • Fix misleading output from gin_desc(). XLOG_GIN_UPDATE_META_PAGE and XLOG_GIN_DELETE_LISTPAGE records were printed with a list link field labeled as "blkno", which was confusing, especially when the link was empty (InvalidBlockNumber). Print the metapage block number instead, since that's what's actually being updated. We could include the link values too as a separate field, but not clear it's worth the trouble. Back-patch to 8.4 where the dubious code was added. http://git.postgresql.org/pg/commitdiff/0ab4db52c0d45763adee3981da4325e7c353e443
  • Update URL for pgtclng project. Thom Brown http://git.postgresql.org/pg/commitdiff/d75829a682fdf832fe9d044b28be597d3f058ec8
  • Remove useless variable to suppress compiler warning. http://git.postgresql.org/pg/commitdiff/a25ef7a5f68728f7f78f798a98c26b773c45937e
  • Further adjustment of comment about qsort_tuple. http://git.postgresql.org/pg/commitdiff/95b9c333b25463283ba07c5ba7dbe79b4e8b4480
  • Fix incorrect make maintainer-clean rule. http://git.postgresql.org/pg/commitdiff/7feecedccef078bb9f39188db2f75c1481b45cc3
  • Improve management of "sticky" entries in contrib/pg_stat_statements. This patch addresses a deficiency in the previous pg_stat_statements patch. We want to give sticky entries an initial "usage" factor high enough that they probably will stick around until their query is completed. However, if the query never completes (eg it gets an error during execution), the entry shouldn't persist indefinitely. Manage this by starting out with a usage setting equal to the (approximate) median usage value within the whole hashtable, but decaying the value much more aggressively than we do for normal entries. Peter Geoghegan http://git.postgresql.org/pg/commitdiff/d5375491f8e391224b48e4bb449995a4642183ea

Simon Riggs a poussé :

Bruce Momjian a poussé :

Heikki Linnakangas a poussé :

  • Do stack-depth checking in all postmaster children. We used to only initialize the stack base pointer when starting up a regular backend, not in other processes. In particular, autovacuum workers can run arbitrary user code, and without stack-depth checking, infinite recursion in e.g an index expression will bring down the whole cluster. The comment about PL/Java using set_stack_base() is not yet true. As the code stands, PL/java still modifies the stack_base_ptr variable directly. However, it's been discussed in the PL/Java mailing list that it should be changed to use the function, because PL/Java is currently oblivious to the register stack used on Itanium. There's another issues with PL/Java, namely that the stack base pointer it sets is not really the base of the stack, it could be something close to the bottom of the stack. That's a separate issue that might need some further changes to this code, but that's a different story. Backpatch to all supported releases. http://git.postgresql.org/pg/commitdiff/ef3883d130cb553003015f3da7fa59415da6f5c9
  • set_stack_base() no longer needs to be called in PostgresMain. This was a thinko in previous commit. Now that stack base pointer is now set in PostmasterMain and SubPostmasterMain, it doesn't need to be set in PostgresMain anymore. http://git.postgresql.org/pg/commitdiff/03529a3ff999b0e4770b3e0b8e342400e383db98

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Etsuro Fujita and Shigeru HANADA traded patches to implement various parts of a PostgreSQL FDW.
  • Gilles Darold sent in some patches to help tell when PostgreSQL is in backup mode.
  • Josh Kupershmidt sent in a patch to fix psql's tab completion for WITH under some circumstances.
  • Heikki Linnakangas and Pavel Stehule traded versions of the CHECK TRIGGER patch.
  • Joachim Wieland sent in two more revisions of the patch to make pg_dump able to operate in parallel.
  • Yeb Havinga sent in two revisions of a patch intended to fix an issue with cursor arguments in named notation.
  • Zoltan Boszormenyi sent in five revisions of a patch to implement a framework to simplify and correctly nest multiplexing more than two timeout sources into the same SIGALRM signal handler.
  • Robert Haas sent in a patch to fix the SLRU replacement algorithm.
  • Peter Eisentraut sent in a patch to rename bytea_agg() to string_agg(), which now covers bytea types.
  • Peter Geoghegan sent in a patch to do some speedups in pg_stat_statements.
  • Alvaro Herrera sent in another revision of the patch to add URI support to libpq, along with some documentation fo the changes.