== PostgreSQL Weekly News - November 16 2014 == The CfP is open for Nordic PostgreSQL Day 2015, which will be held March 11, 2015 in Copenhagen, Denmark. http://2015.nordicpgday.org/cfp/
== PostgreSQL Jobs for November == http://archives.postgresql.org/pgsql-jobs/2014-11/threads.php == PostgreSQL Local == PG-Cuba will be November 25 and 26, 2014 http://postgresql.uci.cu/?p=1087#more-1087 The CfP for FOSDEM PGDay (January 30, 2015) and the FOSDEM PostgreSQL Dev Room (January 31-February 1, 2015) are open until November 24th, 2014. http://fosdem2015.pgconf.eu/callforpapers/ The CfP for PGConf US 2015 is open through December 17th, 2014 Notifications will go out on January 10, 2014. The event takes place March 25-27, 2015 in NYC. http://nyc.pgconf.us/2015/ == 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 da...@fetter.org, German language to p...@pgug.de, Italian language to p...@itpug.org. Spanish language to p...@arpug.com.ar. == Applied Patches == Bruce Momjian pushed: - C comment: mention 1500-02-29 as an invalid date. It is invalid because the Gregorian calendar is used for all years. http://git.postgresql.org/pg/commitdiff/67067f9ae35fcaf7c1a6f3258043cbd0a0380473 Robert Haas pushed: - Tab complete second argument to \c with role names. Ian Barwick http://git.postgresql.org/pg/commitdiff/095d40123cedcdfa81c55f0de113067d95370d57 - Fix potential NULL-pointer dereference. Commit 2781b4bea7db357be59f9a5fd73ca1eb12ff5a79 arranged to defer the setup of after-trigger-related data structures, but AfterTriggerPendingOnRel didn't get the memo. http://git.postgresql.org/pg/commitdiff/c8df9477f8ce48b202de989984f90dd78e1bba31 - Remove incorrect comment. This was introduced by commit 5ea86e6e65dd2da3e9a3464484985d48328e7fe3. Peter Geoghegan http://git.postgresql.org/pg/commitdiff/f1abd78be7c7dc6fce7edaf9262998f3ca3d14be - Move the guts of our Levenshtein implementation into core. The hope is that we can use this to produce better diagnostics in some cases. Peter Geoghegan, reviewed by Michael Paquier, with some further changes by me. http://git.postgresql.org/pg/commitdiff/c0828b78e930a4e085ec52f19fdc850104cb0659 Kevin Grittner pushed: - Fix compiler warning for non-assert builds. Reported by Peter Geoghegan. David Rowley http://git.postgresql.org/pg/commitdiff/96a73fcdace57f0f631c1f56d1cb8a7a0773e93f Álvaro Herrera pushed: - Further code and wording tweaks in BRIN. Besides a couple of typo fixes, per David Rowley, Thom Brown, and Amit Langote, and mentions of BRIN in the general CREATE INDEX page again per David, this includes silencing MSVC compiler warnings (thanks Microsoft) and an additional variable initialization per Coverity scanner. http://git.postgresql.org/pg/commitdiff/1e0b4365c22c9f8a1bc7a5f8339f770c767b402f - BRIN: fix bug in xlog backup block counting. The code that generates the BRIN_XLOG_UPDATE removes the buffer reference when the page that's target for the updated tuple is freshly initialized. This is a pretty usual optimization, but was breaking the case where the revmap buffer, which is referenced in the same WAL record, is getting a backup block: the replay code was using backup block index 1, which is not valid when the update target buffer gets pruned; the revmap buffer gets assigned 0 instead. Make sure to use the correct backup block index for revmap when replaying. Bug reported by Fujii Masao. http://git.postgresql.org/pg/commitdiff/a590f266e44c492d2a252ab9dee0cd88dbe06dc5 - Tweak row-level locking documentation. Move the meat of locking levels to mvcc.sgml, leaving only a link to it in the SELECT reference page. Michael Paquier, with some tweaks by Álvaro http://git.postgresql.org/pg/commitdiff/35fed51626328a3ff54adae4749bef956e1e1099 - Allow interrupting GetMultiXactIdMembers. This function has a loop which can lead to uninterruptible process "stalls" (actually infinite loops) when some bugs are triggered. Avoid that unpleasant situation by adding a check for interrupts in a place that shouldn't degrade performance in the normal case. Backpatch to 9.3. Older branches have an identical loop here, but the aforementioned bugs are only a problem starting in 9.3 so there doesn't seem to be any point in backpatching any further. http://git.postgresql.org/pg/commitdiff/51f9ea25dc4296948eb851a851bb60e0860c70a1 - Reduce disk footprint of brin regression test. Per complaint from Tom Lane. While at it, throw in some extra tests for nulls as well, and make sure that the set of data we insert on the second round is not identical to the first one. Both measures are intended to improve coverage of the test. Also uncomment the ON COMMIT DROP clause on the CREATE TEMP TABLE commands. This doesn't have any effect for someone examining the regression database after the tests are done, but it reduces clutter for those that execute the script directly. http://git.postgresql.org/pg/commitdiff/86cf9a565069755189e08290343d2d62afdd1f52 - Document BRIN's pages_per_range in CREATE INDEX. Author: Michael Paquier http://git.postgresql.org/pg/commitdiff/79172a58ea3e858750c93c61d55411a209c5ac69 - Remove unused InhPaths. Allegedly, the last remaining usages of that struct were removed by 0e99be1c. Author: Peter Geoghegan http://git.postgresql.org/pg/commitdiff/e4d1e264918f4019c86c807e7c349658f7a10397 - postgres_fdw.h: don't pull in rel.h when relcache.h is enough. http://git.postgresql.org/pg/commitdiff/f9ef578d050c509d0f4bc02b3c0a3a0497056a2a - Get rid of SET LOGGED indexes persistence kludge. This removes ATChangeIndexesPersistence() introduced by f41872d0c1239d36 which was too ugly to live for long. Instead, the correct persistence marking is passed all the way down to reindex_index, so that the transient relation built to contain the index relfilenode can get marked correctly right from the start. Author: Fabrízio de Royes Mello. Review and editorialization by Michael Paquier and Álvaro Herrera http://git.postgresql.org/pg/commitdiff/85b506bbfc2937c9abdfcce4e01a8feca8e64ee8 Tom Lane pushed: - Ensure that RowExprs and whole-row Vars produce the expected column names. At one time it wasn't terribly important what column names were associated with the fields of a composite Datum, but since the introduction of operations like row_to_json(), it's important that looking up the rowtype ID embedded in the Datum returns the column names that users would expect. That did not work terribly well before this patch: you could get the column names of the underlying table, or column aliases from any level of the query, depending on minor details of the plan tree. You could even get totally empty field names, which is disastrous for cases like row_to_json(). To fix this for whole-row Vars, look to the RTE referenced by the Var, and make sure its column aliases are applied to the rowtype associated with the result Datums. This is a tad scary because we might have to return a transient RECORD type even though the Var is declared as having some named rowtype. In principle it should be all right because the record type will still be physically compatible with the named rowtype; but I had to weaken one Assert in ExecEvalConvertRowtype, and there might be third-party code containing similar assumptions. Similarly, RowExprs have to be willing to override the column names coming from a named composite result type and produce a RECORD when the column aliases visible at the site of the RowExpr differ from the underlying table's column names. In passing, revert the decision made in commit 398f70ec070fe601 to add an alias-list argument to ExecTypeFromExprList: better to provide that functionality in a separate function. This also reverts most of the code changes in d68581483564ec0f, which we don't need because we're no longer depending on the tupdesc found in the child plan node's result slot to be blessed. Back-patch to 9.4, but not earlier, since this solution changes the results in some cases that users might not have realized were buggy. We'll apply a more restricted form of this patch in older branches. http://git.postgresql.org/pg/commitdiff/bf7ca15875988a88e97302e012d7c4808bef3ea9 - Fix dependency searching for case where column is visited before table. When the recursive search in dependency.c visits a column and then later visits the whole table containing the column, it needs to propagate the drop-context flags for the table to the existing target-object entry for the column. Otherwise we might refuse the DROP (if not CASCADE) on the incorrect grounds that there was no automatic drop pathway to the column. Remarkably, this has not been reported before, though it's possible at least when an extension creates both a datatype and a table using that datatype. Rather than just marking the column as allowed to be dropped, it might seem good to skip the DROP COLUMN step altogether, since the later DROP of the table will surely get the job done. The problem with that is that the datatype would then be dropped before the table (since the whole situation occurred because we visited the datatype, and then recursed to the dependent column, before visiting the table). That seems pretty risky, and the case is rare enough that it doesn't seem worth expending a lot of effort or risk to make the drops happen in a safe order. So we just play dumb and delete the column separately according to the existing drop ordering rules. Per report from Petr Jelinek, though this is different from his proposed patch. Back-patch to 9.1, where extensions were introduced. There's currently no evidence that such cases can arise before 9.1, and in any case we would also need to back-patch cb5c2ba2d82688d29b5902d86b993a54355cad4d to 9.0 if we wanted to back-patch this. http://git.postgresql.org/pg/commitdiff/2edfc021c64ac2b15c9e9f9ada037ad12150bfa9 - Loop when necessary in contrib/pgcrypto's pktreader_pull(). This fixes a scenario in which pgp_sym_decrypt() failed with "Wrong key or corrupt data" on messages whose length is 6 less than a power of 2. Per bug #11905 from Connor Penhale. Fix by Marko Tiikkaja, regression test case from Jeff Janes. http://git.postgresql.org/pg/commitdiff/f2ad2bdd0abfb1ce8f274fbb01a82e209f4cc122 - Explicitly support the case that a plancache's raw_parse_tree is NULL. This only happens if a client issues a Parse message with an empty query string, which is a bit odd; but since it is explicitly called out as legal by our FE/BE protocol spec, we'd probably better continue to allow it. Fix by adding tests everywhere that the raw_parse_tree field is passed to functions that don't or shouldn't accept NULL. Also make it clear in the relevant comments that NULL is an expected case. This reverts commits a73c9dbab0165b3395dfe8a44a7dfd16166963c4 and 2e9650cbcff8c8fb0d9ef807c73a44f241822eee, which fixed specific crash symptoms by hacking things at what now seems to be the wrong end, ie the callee functions. Making the callees allow NULL is superficially more robust, but it's not always true that there is a defensible thing for the callee to do in such cases. The caller has more context and is better able to decide what the empty-query case ought to do. Per followup discussion of bug #11335. Back-patch to 9.2. The code before that is sufficiently different that it would require development of a separate patch, which doesn't seem worthwhile for what is believed to be an essentially cosmetic change. http://git.postgresql.org/pg/commitdiff/677708032c4a4d37cdb2a4bd45726fc260308db7 - Fix pg_dumpall to restore its ability to dump from ancient servers. Fix breakage induced by commits d8d3d2a4f37f6df5d0118b7f5211978cca22091a and 463f2625a5fb183b6a8925ccde98bb3889f921d9: pg_dumpall has crashed when attempting to dump from pre-8.1 servers since then, due to faulty construction of the query used for dumping roles from older servers. The query was erroneous as of the earlier commit, but it wasn't exposed unless you tried to use --binary-upgrade, which you presumably wouldn't with a pre-8.1 server. However commit 463f2625a made it fail always. In HEAD, also fix additional breakage induced in the same query by commit 491c029dbc4206779cf659aa0ff986af7831d2ff, which evidently wasn't tested against pre-8.1 servers either. The bug is only latent in 9.1 because 463f2625a hadn't landed yet, but it seems best to back-patch all branches containing the faulty query. Gilles Darold http://git.postgresql.org/pg/commitdiff/be09ceb21882507bff95d74bad0ebe25efc227bd - Document evaluation-order considerations for aggregate functions. The SELECT reference page didn't really address the question of when aggregate function evaluation occurs, nor did the "expression evaluation rules" documentation mention that CASE can't be used to control whether an aggregate gets evaluated or not. Improve that. Per discussion of bug #11661. Original text by Marti Raudsepp and Michael Paquier, rewritten significantly by me. http://git.postgresql.org/pg/commitdiff/0ce627d465f534a3234750a5b398664dfece4102 Heikki Linnakangas pushed: - Fix compilation failure on MIPS. Rémi Zara http://git.postgresql.org/pg/commitdiff/baf7b3a503342f263558b7dbf6d3c694622ab3c5 - Really fix compilation failure on MIPS. I missed an additional colon in previous patch. Oops. To make that mistake less likely in the future, add comments as placeholders for unused inputs and outputs in inline assembly. http://git.postgresql.org/pg/commitdiff/ae667f778d9b7b8ed5a9a8b93abd868690a8ae14 - Fix XLogReadBufferForRedoExtended to get cleanup lock when asked to do so. http://git.postgresql.org/pg/commitdiff/34402ae351e71f852a6c2fee7861a66d0dbeb24c - Fix race condition between hot standby and restoring a full-page image. There was a window in RestoreBackupBlock where a page would be zeroed out, but not yet locked. If a backend pinned and locked the page in that window, it saw the zeroed page instead of the old page or new page contents, which could lead to missing rows in a result set, or errors. To fix, replace RBM_ZERO with RBM_ZERO_AND_LOCK, which atomically pins, zeroes, and locks the page, if it's not in the buffer cache already. In stable branches, the old RBM_ZERO constant is renamed to RBM_DO_NOT_USE, to avoid breaking any 3rd party extensions that might use RBM_ZERO. More importantly, this avoids renumbering the other enum values, which would cause even bigger confusion in extensions that use ReadBufferExtended, but haven't been recompiled. Backpatch to all supported versions; this has been racy since hot standby was introduced. http://git.postgresql.org/pg/commitdiff/81c45081960f39351c38cd53554bb3788af54023 Fujii Masao pushed: - Add GUC and storage parameter to set the maximum size of GIN pending list. Previously the maximum size of GIN pending list was controlled only by work_mem. But the reasonable value of work_mem and the reasonable size of the list are basically not the same, so it was not appropriate to control both of them by only one GUC, i.e., work_mem. This commit separates new GUC, pending_list_cleanup_size, from work_mem to allow users to control only the size of the list. Also this commit adds pending_list_cleanup_size as new storage parameter to allow users to specify the size of the list per index. This is useful, for example, when users want to increase the size of the list only for the GIN index which can be updated heavily, and decrease it otherwise. Reviewed by Etsuro Fujita. http://git.postgresql.org/pg/commitdiff/a1b395b6a26ae80cde17fdfd2def8d351872f399 - Add generate_series(numeric, numeric). Платон Малюгин. Reviewed by Michael Paquier, Ali Akbar and Marti Raudsepp http://git.postgresql.org/pg/commitdiff/1871c892021055532344266d7429b63f76a892c2 - Rename pending_list_cleanup_size to gin_pending_list_limit. Since this parameter is only for GIN index, it's better to add "gin" to the parameter name for easier understanding. http://git.postgresql.org/pg/commitdiff/c291503b1c8250c7ba6ca900b7ba2f85a64b1eb6 Peter Eisentraut pushed: - Message improvements http://git.postgresql.org/pg/commitdiff/8339f33d68e08d24eb316971a0ac73af162d52b3 - doc: Add index entry for "hypothetical-set aggregate" http://git.postgresql.org/pg/commitdiff/1d69ae419d04fa7919fa282224a566499f3a0fd0 - Improve logical decoding log messages. suggestions from Robert Haas http://git.postgresql.org/pg/commitdiff/a15d387c22b794b0d2d037ce9f7b379ea8f153c0 - Translation updates http://git.postgresql.org/pg/commitdiff/7466a1b75f01c10c2eb33ed50663fe27f66194e9 Noah Misch pushed: - Use just one database connection in the "tablespace" test. On Windows, DROP TABLESPACE has a race condition when run concurrently with other processes having opened files in the tablespace. This led to a rare failure on buildfarm member frogmouth. Back-patch to 9.4, where the reconnection was introduced. http://git.postgresql.org/pg/commitdiff/28245b8424e29808f4f714482077a762cab0c5c5 Andres Freund pushed: - Add interrupt checks to contrib/pg_prewarm. Currently the extension's pg_prewarm() function didn't check interrupts once it started "warming" data. Since individual calls can take a long while it's important for them to be interruptible. Backpatch to 9.4 where pg_prewarm was introduced. http://git.postgresql.org/pg/commitdiff/bd4ae0f396b36955c92f26c0058e7dc0452db817 - Fix several weaknesses in slot and logical replication on-disk serialization. Heikki noticed in 544e23c0.8090...@vmware.com that slot.c and snapbuild.c were missing the FIN_CRC32 call when computing/checking checksums of on disk files. That doesn't lower the the error detection capabilities of the checksum, but is inconsistent with other usages. In a followup mail Heikki also noticed that, contrary to a comment, the 'version' and 'length' struct fields of replication slot's on disk data where not covered by the checksum. That's not likely to lead to actually missed corruption as those fields are cross checked with the expected version and the actual file length. But it's wrong nonetheless. As fixing these issues makes existing on disk files unreadable, bump the expected versions of on disk files for both slots and logical decoding historic catalog snapshots. This means that loading old files will fail with ERROR: "replication slot file ... has unsupported version 1" and ERROR: "snapbuild state file ... has unsupported version 1 instead of 2" respectively. Given the low likelihood of anybody already using these new features in a production setup that seems acceptable. Fixing these issues made me notice that there's no regression test covering the loading of historic snapshot from disk - so add one. Backpatch to 9.4 where these features were introduced. http://git.postgresql.org/pg/commitdiff/ec5896aed3c01da24c1f335f138817e9890d68b6 - Fix xmin/xmax horizon computation during logical decoding initialization. When building the initial historic catalog snapshot there were scenarios where snapbuild.c would use incorrect xmin/xmax values when starting from a xl_running_xacts record. The values used were always a bit suspect, but happened to be correct in the easy to test cases. Notably the values used when the the initial snapshot was computed while no other transactions were running were correct. This is likely to be the cause of the occasional buildfarm failures on animals markhor and tick; but it's quite possible to reproduce problems without CLOBBER_CACHE_ALWAYS. Backpatch to 9.4, where logical decoding was introduced. http://git.postgresql.org/pg/commitdiff/5a2c184058c51a41b855b9e824102d1395402ffa - Fix and improve cache invalidation logic for logical decoding. There are basically three situations in which logical decoding needs to perform cache invalidation. During/After replaying a transaction with catalog changes, when skipping a uninteresting transaction that performed catalog changes and when erroring out while replaying a transaction. Unfortunately these three cases were all done slightly differently - partially because 8de3e410fa, which greatly simplifies matters, got committed in the midst of the development of logical decoding. The actually problematic case was when logical decoding skipped transaction commits (and thus processed invalidations). When used via the SQL interface cache invalidation could access the catalog - bad, because we didn't set up enough state to allow that correctly. It'd not be hard to setup sufficient state, but the simpler solution is to always perform cache invalidation outside a valid transaction. Also make the different cache invalidation cases look as similar as possible, to ease code review. This fixes the assertion failure reported by Antonin Houska in 53ee02d9.7040...@gmail.com. The presented testcase has been expanded into a regression test. Backpatch to 9.4, where logical decoding was introduced. http://git.postgresql.org/pg/commitdiff/89fd41b390a46202937f647043043d5b0a4eadae - Adapt valgrind.supp to the XLogInsert() split. The CRC computation now happens in XLogInsertRecord(), not XLogInsert() itself anymore. http://git.postgresql.org/pg/commitdiff/473f162ce1faabeb2d572b9805311081919e5deb - Move BufferGetBlockNumber() out of heap_page_is_all_visible()'s inner loop. In some workloads BufferGetBlockNumber() shows up in profiles due to the sheer number of calls to it (and because it causes cache misses). The compiler can't move it out of the loop because it's a full extern function call... http://git.postgresql.org/pg/commitdiff/0c5af0a537a2d6320eb8ef7f401401aa1f47b79e - Add valgrind suppression for pg_atomic_init_u64. pg_atomic_init_u64 (indirectly) uses compare/exchange to guarantee atomic writes on platforms where compare/exchange is available, but 64bit writes aren't atomic (yes, those exist). That leads to a harmless read of the initial value of variable. http://git.postgresql.org/pg/commitdiff/6c878edc1df9d4d9ad7ed4a7e1c34c0bf0f622b9 - Fix initdb --sync-only to also sync tablespaces. 630cd14426dc added initdb --sync-only, for use by pg_upgrade, by just exposing the existing fsync code. That's wrong, because initdb so far had absolutely no reason to deal with tablespaces. Fix --sync-only by additionally explicitly syncing each of the tablespaces. Backpatch to 9.3 where --sync-only was introduced. Abhijit Menon-Sen and Andres Freund http://git.postgresql.org/pg/commitdiff/522c85a6a27b614589543eddb68a4c8f7fcac901 - Ensure unlogged tables are reset even if crash recovery errors out. Unlogged relations are reset at the end of crash recovery as they're only synced to disk during a proper shutdown. Unfortunately that and later steps can fail, e.g. due to running out of space. This reset was, up to now performed after marking the database as having finished crash recovery successfully. As out of space errors trigger a crash restart that could lead to the situation that not all unlogged relations are reset. Once that happend usage of unlogged relations could yield errors like "could not open file "...": No such file or directory". Luckily clusters that show the problem can be fixed by performing a immediate shutdown, and starting the database again. To fix, just call ResetUnloggedRelations(UNLOGGED_RELATION_INIT) earlier, before marking the database as having successfully recovered. Discussion: 20140912112246.ga4...@alap3.anarazel.de Backpatch to 9.1 where unlogged tables were introduced. Abhijit Menon-Sen and Andres Freund http://git.postgresql.org/pg/commitdiff/d3586fc8aa5d9365a5c50cb5e555971eb633a4ec - Sync unlogged relations to disk after they have been reset. Unlogged relations are only reset when performing a unclean restart. That means they have to be synced to disk during clean shutdowns. During normal processing that's achieved by registering a buffer's file to be fsynced at the next checkpoint when flushed. But ResetUnloggedRelations() doesn't go through the buffer manager, so nothing will force reset relations to disk before the next shutdown checkpoint. So just make ResetUnloggedRelations() fsync the newly created main forks to disk. Discussion: 20140912112246.ga4...@alap3.anarazel.de Backpatch to 9.1 where unlogged tables were introduced. Abhijit Menon-Sen and Andres Freund http://git.postgresql.org/pg/commitdiff/98ec7fd903bbd4ab1694de5aaa4f7bb62935c58d Stephen Frost pushed: - Revert change to ALTER TABLESPACE summary. When ALTER TABLESPACE MOVE ALL was changed to be ALTER TABLE ALL IN TABLESPACE, the ALTER TABLESPACE summary should have been adjusted back to its original definition. Patch by Thom Brown (thanks!). http://git.postgresql.org/pg/commitdiff/155c0f24b7d370eb57fb8dde0447e11e41c405c2 - Clean up includes from RLS patch The initial patch for RLS mistakenly included headers associated with the executor and planner bits in rewrite/rowsecurity.h. Per policy and general good sense, executor headers should not be included in planner headers or vice versa. The include of execnodes.h was a mistaken holdover from previous versions, while the include of relation.h was used for Relation's definition, which should have been coming from utils/relcache.h. This patch cleans these issues up, adds comments to the RowSecurityPolicy struct and the RowSecurityConfigType enum, and changes Relation->rsdesc to Relation->rd_rsdesc to follow Relation field naming convention. Additionally, utils/rel.h was including rewrite/rowsecurity.h, which wasn't a great idea since that was pulling in things not really needed in utils/rel.h (which gets included in quite a few places). Instead, use 'struct RowSecurityDesc' for the rd_rsdesc field and add comments explaining why. Lastly, add an include into access/nbtree/nbtsort.c for utils/sortsupport.h, which was evidently missed due to the above mess. Pointed out by Tom in 16970.1415838...@sss.pgh.pa.us; note that the concerns regarding a similar situation in the custom-path commit still need to be addressed. http://git.postgresql.org/pg/commitdiff/80eacaa3cdcd10383c333f6f4625af8cee1f7bee Simon Riggs pushed: - Emit msg re skipping ANALYZE for absent inh tree. When checking a table that has an inheritance tree marked, if no child tables remain, we skip ANALYZE. This patch emits a message to show that the action has been skipped. Author: Etsuro Fujita. Reviewer: Furuya Osamu http://git.postgresql.org/pg/commitdiff/0f66d2120154e51960a21062b214d468782d8554 Magnus Hagander pushed: - Restructure doc sections about statistics views. Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start. http://git.postgresql.org/pg/commitdiff/386c9b73839bd4cae489451122801c31496d20e8 - Mention the TZ environment variable for initdb. Daniel Gustafsson http://git.postgresql.org/pg/commitdiff/d883b916a947a3c6b1b88d386d5add62862bf8cf == Rejected Patches (for now) == No one was disappointed this week :-) == Pending Patches == Peter Geoghegan sent in a pair of patches, one to add abbreviated sortsupport keys, the other to estimate total number of rows to be sorted. Tomas Vondra sent in another revision of a patch to implement multi-column statistics. Peter Geoghegan sent in another revision of a patch to implement INSERT ... ON CONFLICT. Magnus Hagander sent in another revision of a patch to implement an SSL information view. Kaigai Kouhei sent in a patch to add a missing Assert() to the custom plan API. Michael Paquier sent in another revision of a patch to compress full-page writes. Kyotaro HORIGUCHI sent in two more revisions of a patch to implement ALTER RULE ... CURRENT_USER. Simon Riggs sent in a patch to add an option to pg_dump which would have it dump constraints as NOT VALID. Michael Paquier sent in another revision of a patch to implement REINDEX CONCURRENTLY. Heikki Linnakangas sent in three more revisions of a patch to change the WAL format and API. Fabrízio de Royes Mello and Michael Paquier traded patches to implement ALTER TABLE ... SET LOGGED. Etsuro Fujita sent in a patch to fix some odd behavior in the postgres_fdw. Robert Haas sent a patch to add infrastructure to save and restore GUC values, and one which depends on it to run commands in a background worker and get the results. Fujii Masao sent in another revision of a patch to add fsync feedback to pg_receivexlog --status-interval. Andreas Karlsson sent in two more revisions of a patch to use 128-bit integers for sum, avg and statistics aggregates. Petr (PJMODOS) Jelinek sent in another revision of a patch to track commit timestamps. Etsuro Fujita sent in two revisions of a patch to fix some typos in the CREATE TABLE documentation. Alexander Shulgin sent in a PoC patch to allow timing out transactions in the "Idle In Transaction" state. Andrew Dunstan sent in a patch to control psql's interaction with the pager at a finer grain. David Rowley sent in another revision of a patch to remove inner joins under certain conditions. Michael Paquier sent in two revisions of a patch to fix an issue where PostgreSQL doesn't stop properly when --slot option is specified with pg_receivexlog. Pavel Stehule sent in another revision of a patch to add asciidoc as an output option for psql. Michael Paquier sent in another revision of a patch to refactor the code for sync node detection. -- Sent via pgsql-announce mailing list (pgsql-announce@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-announce
