== PostgreSQL Weekly News - March 01 2015 == The Manchester England PostgreSQL Users' Group is rebooting March 4th. Details and R, SVP, below. http://www.meetup.com/The-Manchester-PostgreSQL-Meetup/
== PostgreSQL Local == pgDaySF 2015 will be held March 10, 2015 in Burlingame, California. http://sfpostgres.org/pgday-sf-2015-call-for-speakers-and-sponsors/ Registration for Nordic PostgreSQL Day, March 11, 2015 in Copenhagen, Denmark, is open. http://2015.nordicpgday.org/registration/ PGConf US 2015 takes place March 25-27, 2015 in NYC. http://nyc.pgconf.us/2015/ The CfP for the second Swiss Postgres Conference, to be held June 25-26, 2015 at HSR Rapperswil, is open until April 1. http://www.postgres-conference.ch/cfp/ India PostgreSQL UserGroup will hold a PGday in Bengaluru, Karnataka, India on April 11, 2015. RSVP at http://www.meetup.com/India-PUG/events/220553997/ PGCon 2015 is June 16-20 in Ottawa, Canada. http://www.pgcon.org/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 == Heikki Linnakangas pushed: - Fix potential deadlock with libpq non-blocking mode. If libpq output buffer is full, pqSendSome() function tries to drain any incoming data. This avoids deadlock, if the server e.g. sends a lot of NOTICE messages, and blocks until we read them. However, pqSendSome() only did that in blocking mode. In non-blocking mode, the deadlock could still happen. To fix, take a two-pronged approach: 1. Change the documentation to instruct that when PQflush() returns 1, you should wait for both read- and write-ready, and call PQconsumeInput() if it becomes read-ready. That fixes the deadlock, but applications are not going to change overnight. 2. In pqSendSome(), drain the input buffer before returning 1. This alleviates the problem for applications that only wait for write-ready. In particular, a slow but steady stream of NOTICE messages during COPY FROM STDIN will no longer cause a deadlock. The risk remains that the server attempts to send a large burst of data and fills its output buffer, and at the same time the client also sends enough data to fill its output buffer. The application will deadlock if it goes to sleep, waiting for the socket to become write-ready, before the server's data arrives. In practice, NOTICE messages and such that the server might be sending are usually short, so it's highly unlikely that the server would fill its output buffer so quickly. Backpatch to all supported versions. http://git.postgresql.org/pg/commitdiff/2a3f6e368babdac7b586a7d43105af60fc08b1a3 - Refactor unit conversions code in guc.c. Replace the if-switch-case constructs with two conversion tables, containing all the supported conversions between human-readable unit strings and the base units used in GUC variables. This makes the code easier to read, and makes adding new units simpler. http://git.postgresql.org/pg/commitdiff/1b6302647302f459fdb63008c3842a1b0d43d1b7 - Renumber GUC_* constants. This moves all the regular flags back together (for aesthetic reasons), and makes room for more GUC_UNIT_* types. http://git.postgresql.org/pg/commitdiff/0fec000365c25fd89ea583673de226e816dba60f - Replace checkpoint_segments with min_wal_size and max_wal_size. Instead of having a single knob (checkpoint_segments) that both triggers checkpoints, and determines how many checkpoints to recycle, they are now separate concerns. There is still an internal variable called CheckpointSegments, which triggers checkpoints. But it no longer determines how many segments to recycle at a checkpoint. That is now auto-tuned by keeping a moving average of the distance between checkpoints (in bytes), and trying to keep that many segments in reserve. The advantage of this is that you can set max_wal_size very high, but the system won't actually consume that much space if there isn't any need for it. The min_wal_size sets a floor for that; you can effectively disable the auto-tuning behavior by setting min_wal_size equal to max_wal_size. The max_wal_size setting is now the actual target size of WAL at which a new checkpoint is triggered, instead of the distance between checkpoints. Previously, you could calculate the actual WAL usage with the formula "(2 + checkpoint_completion_target) * checkpoint_segments + 1". With this patch, you set the desired WAL usage with max_wal_size, and the system calculates the appropriate CheckpointSegments with the reverse of that formula. That's a lot more intuitive for administrators to set. Reviewed by Amit Kapila and Venkata Balaji N. http://git.postgresql.org/pg/commitdiff/88e982302684246e8af785e78a467ac37c76dee9 - Fix typo in README. Kyotaro Horiguchi http://git.postgresql.org/pg/commitdiff/dd58c6098f2f2fcea71c7125f9594268a24a38ad - Fix recovery_command -> restore_command typo in 8.3 release notes. Kyotaro Horiguchi http://git.postgresql.org/pg/commitdiff/347c74320d10bee458d1fec159aeda7143d31bfb Fujii Masao pushed: - Add GUC to control the time to wait before retrieving WAL after failed attempt. Previously when the standby server failed to retrieve WAL files from any sources (i.e., streaming replication, local pg_xlog directory or WAL archive), it always waited for five seconds (hard-coded) before the next attempt. For example, this is problematic in warm-standby because restore_command can fail every five seconds even while new WAL file is expected to be unavailable for a long time and flood the log files with its error messages. This commit adds new parameter, wal_retrieve_retry_interval, to control that wait time. Alexey Vasiliev and Michael Paquier, reviewed by Andres Freund and me. http://git.postgresql.org/pg/commitdiff/5d2b45e3f78a85639f30431181c06d4c3221c5a1 - Add note about how to make the SRF detoasted arguments live accross calls. Andrew Gierth and Ali Akbar http://git.postgresql.org/pg/commitdiff/a7920b872fff36668a2d33157609024b851b5c2e Andres Freund pushed: - Guard against spurious signals in LockBufferForCleanup. When LockBufferForCleanup() has to wait for getting a cleanup lock on a buffer it does so by setting a flag in the buffer header and then wait for other backends to signal it using ProcWaitForSignal(). Unfortunately LockBufferForCleanup() missed that ProcWaitForSignal() can return for other reasons than the signal it is hoping for. If such a spurious signal arrives the wait flags on the buffer header will still be set. That then triggers "ERROR: multiple backends attempting to wait for pincount 1". The fix is simple, unset the flag if still set when retrying. That implies an additional spinlock acquisition/release, but that's unlikely to matter given the cost of waiting for a cleanup lock. Alternatively it'd have been possible to move responsibility for maintaining the relevant flag to the waiter all together, but that might have had negative consequences due to possible floods of signals. Besides being more invasive. This looks to be a very longstanding bug. The relevant code in LockBufferForCleanup() hasn't changed materially since its introduction and ProcWaitForSignal() was documented to return for unrelated reasons since 8.2. The master only patch series removing ImmediateInterruptOK made it much easier to hit though, as ProcSendSignal/ProcWaitForSignal now uses a latch shared with other tasks. Per discussion with Kevin Grittner, Tom Lane and me. Backpatch to all supported branches. Discussion: 11553.1423805...@sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/bc208a5a2f9eb34bf795374fa5381e0c82073255 - Reconsider when to wait for WAL flushes/syncrep during commit. Up to now RecordTransactionCommit() waited for WAL to be flushed (if synchronous_commit != off) and to be synchronously replicated (if enabled), even if a transaction did not have a xid assigned. The primary reason for that is that sequence's nextval() did not assign a xid, but are worthwhile to wait for on commit. This can be problematic because sometimes read only transactions do write WAL, e.g. HOT page prune records. That then could lead to read only transactions having to wait during commit. Not something people expect in a read only transaction. This lead to such strange symptoms as backends being seemingly stuck during connection establishment when all synchronous replicas are down. Especially annoying when said stuck connection is the standby trying to reconnect to allow syncrep again... This behavior also is involved in a rather complicated <= 9.4 bug where the transaction started by catchup interrupt processing waited for syncrep using latches, but didn't get the wakeup because it was already running inside the same overloaded signal handler. Fix the issue here doesn't properly solve that issue, merely papers over the problems. In 9.5 catchup interrupts aren't processed out of signal handlers anymore. To fix all this, make nextval() acquire a top level xid, and only wait for transaction commit if a transaction both acquired a xid and emitted WAL records. If only a xid has been assigned we don't uselessly want to wait just because of writes to temporary/unlogged tables; if only WAL has been written we don't want to wait just because of HOT prunes. The xid assignment in nextval() is unlikely to cause overhead in real-world workloads. For one it only happens SEQ_LOG_VALS/32 values anyway, for another only usage of nextval() without using the result in an insert or similar is affected. Discussion: 20150223165359.gf30...@awork2.anarazel.de, 369698E947874884A77849D8FE3680C2@maumau, 5CF4ABBA67674088B3941894E22A0D25@maumau Per complaint from maumau and Thom Brown Backpatch all the way back; 9.0 doesn't have syncrep, but it seems better to be consistent behavior across all maintained branches. http://git.postgresql.org/pg/commitdiff/fd6a3f3ad4067f1b8fc28e9de6e99e5936d82161 Tom Lane pushed: - Further tweaking of raw grammar output to distinguish different inputs. Use a different A_Expr_Kind for LIKE/ILIKE/SIMILAR TO constructs, so that they can be distinguished from direct invocation of the underlying operators. Also, postpone selection of the operator name when transforming "x IN (select)" to "x = ANY (select)", so that those syntaxes can be told apart at parse analysis time. I had originally thought I'd also have to do something special for the syntaxes IS NOT DISTINCT FROM, IS NOT DOCUMENT, and x NOT IN (SELECT...), which the grammar translates as though they were NOT (construct). On reflection though, we can distinguish those cases reliably by noting whether the parse location shown for the NOT is the same as for its child node. This only requires tweaking the parse locations for NOT IN, which I've done here. These changes should have no effect outside the parser; they're just in support of being able to give accurate warnings for planned operator precedence changes. http://git.postgresql.org/pg/commitdiff/56be925e4b8f5b1c0e6716ca5cbe0360d1229f50 - Improve parser's one-extra-token lookahead mechanism. There are a couple of places in our grammar that fail to be strict LALR(1), by requiring more than a single token of lookahead to decide what to do. Up to now we've dealt with that by using a filter between the lexer and parser that merges adjacent tokens into one in the places where two tokens of lookahead are necessary. But that creates a number of user-visible anomalies, for instance that you can't name a CTE "ordinality" because "WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one token. I realized that there's a better way. In this patch, we still do the lookahead basically as before, but we never merge the second token into the first; we replace just the first token by a special lookahead symbol when one of the lookahead pairs is seen. This requires a couple extra productions in the grammar, but it involves fewer special tokens, so that the grammar tables come out a bit smaller than before. The filter logic is no slower than before, perhaps a bit faster. I also fixed the filter logic so that when backing up after a lookahead, the current token's terminator is correctly restored; this eliminates some weird behavior in error message issuance, as is shown by the one change in existing regression test outputs. I believe that this patch entirely eliminates odd behaviors caused by lookahead for WITH. It doesn't really improve the situation for NULLS followed by FIRST/LAST unfortunately: those sequences still act like a reserved word, even though there are cases where they should be seen as two ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented with additional grammar hacks but couldn't find any simple solution for that. Still, this is better than before, and it seems much more likely that we *could* somehow solve the NULLS case on the basis of this filter behavior than the previous one. http://git.postgresql.org/pg/commitdiff/d809fd0008a2e26de463f47b7aba0365264078f3 - Fix dumping of views that are just VALUES(...) but have column aliases. The "simple" path for printing VALUES clauses doesn't work if we need to attach nondefault column aliases, because there's noplace to do that in the minimal VALUES() syntax. So modify get_simple_values_rte() to detect nondefault aliases and treat that as a non-simple case. This further exposes that the "non-simple" path never actually worked; it didn't produce valid syntax. Fix that too. Per bug #12789 from Curtis McEnroe, and analysis by Andrew Gierth. Back-patch to all supported branches. Before 9.3, this also requires back-patching the part of commit 092d7ded29f36b0539046b23b81b9f0bf2d637f1 that created get_simple_values_rte() to begin with; inserting the extra test into the old factorization of that logic would've been too messy. http://git.postgresql.org/pg/commitdiff/e9f1c01b71dcd11c86fc8516c06dae2e784b96fd - Fix over-optimistic caching in fetch_array_arg_replace_nulls(). When I rewrote this in commit 56a79a869bedc4bf6c35853642694cc0b0594dd2, I forgot that it's possible for the input array type to change from one call to the next (this can happen when applying the function to pg_statistic columns, for instance). Fix that. http://git.postgresql.org/pg/commitdiff/77903ede08845e55bd2a6c99b52d8da6926d6e84 - Redefine MemoryContextReset() as deleting, not resetting, child contexts. That is, MemoryContextReset() now means what was formerly meant by MemoryContextResetAndDeleteChildren(), and the latter is now just a macro alias for the former. If you really want the functionality that was formerly provided by MemoryContextReset(), what you have to do is MemoryContextResetChildren() plus MemoryContextResetOnly() (which is a new API to reset *only* the named context and not touch its children). The reason for this change is that near fifteen years of experience has proven that there is noplace where old-style MemoryContextReset() is actually what you want. Making that the default behavior has led to lots of context-leakage bugs, while we've not found anyplace where it's actually necessary to keep the child contexts; at least the standard regression tests do not reveal anyplace where this change breaks anything. And there are upcoming patches that will introduce additional reasons why child contexts need to be removed. We could change existing calls of MemoryContextResetAndDeleteChildren to be just MemoryContextReset, but for the moment I'll leave them alone; they're not costing anything. http://git.postgresql.org/pg/commitdiff/eaa5808e8ec4e82ce1a87103a6b6f687666e4e4c - Suppress uninitialized-variable warning from less-bright compilers. The type variable must get set on first iteration of the while loop, but there are reasonably modern gcc versions that don't realize that. Initialize it with a dummy value. This undoes a removal of initialization in commit 654809e770ce270c0bb9de726c5df1ab193d60f0. http://git.postgresql.org/pg/commitdiff/d61f1a93271b859938b6cdb301a367cdb8abf81c - Improve mmgr README. Add documentation about the new reset callback mechanism. Also, at long last, recast the existing text so that it describes the current context mechanisms as established fact rather than something we're going to implement. Shoulda done that in 2001 or so ... http://git.postgresql.org/pg/commitdiff/c4f4c7ca99169ac609df67c2d0eb78162484420c - Fix planning of star-schema-style queries. Part of the intent of the parameterized-path mechanism was to handle star-schema queries efficiently, but some overly-restrictive search limiting logic added in commit e2fa76d80ba571d4de8992de6386536867250474 prevented such cases from working as desired. Fix that and add a regression test about it. Per gripe from Marc Cousin. This is arguably a bug rather than a new feature, so back-patch to 9.2 where parameterized paths were introduced. http://git.postgresql.org/pg/commitdiff/b514a7460d9127ddda6598307272c701cbb133b7 - Track typmods in plpgsql expression evaluation and assignment. The main value of this change is to avoid expensive I/O conversions when assigning to a variable that has a typmod specification, if the value to be assigned is already known to have the right typmod. This is particularly valuable for arrays with typmod specifications; formerly, in an assignment to an array element the entire array would invariably get put through double I/O conversion to check the typmod, to absolutely no purpose since we'd already properly coerced the new element value. Extracted from my "expanded arrays" patch; this seems worth committing separately, whatever becomes of that patch, since it's really an independent issue. As long as we're changing the function signatures, take the opportunity to rationalize the argument lists of exec_assign_value, exec_cast_value, and exec_simple_cast_value; that is, put the arguments into a saner order, and get rid of the bizarre choice to pass exec_assign_value's isNull flag by reference. http://git.postgresql.org/pg/commitdiff/e524cbdc45ec6d677b1dd49ee64dd403959eda0f - Invent a memory context reset/delete callback mechanism. This allows cleanup actions to be registered to be called just before a particular memory context's contents are flushed (either by deletion or MemoryContextReset). The patch in itself has no use-cases for this, but several likely reasons for wanting this exist. In passing, per discussion, rearrange some boolean fields in struct MemoryContextData so as to avoid wasted padding space. For safety, this requires making allowInCritSection's existence unconditional; but I think that's a better approach than what was there anyway. http://git.postgresql.org/pg/commitdiff/f65e8270587f3e9b8224e20f7d020ed1f816dfe1 - Move memory context callback declarations into palloc.h. Initial experience with this feature suggests that instances of MemoryContextCallback are likely to propagate into some widely-used headers over time. As things stood, that would result in pulling memutils.h or at least memnodes.h into common headers, which does not seem desirable. Instead, let's decide that this feature is part of the "ordinary palloc user" API rather than the "specialized context management" API, and as such should be declared in palloc.h not memutils.h. http://git.postgresql.org/pg/commitdiff/097fe194aa7c590b4fa43d5e40c083940859c286 - Use the typcache to cache constraints for domain types. Previously, we cached domain constraints for the life of a query, or really for the life of the FmgrInfo struct that was used to invoke domain_in() or domain_check(). But plpgsql (and probably other places) are set up to cache such FmgrInfos for the whole lifespan of a session, which meant they could be enforcing really stale sets of constraints. On the other hand, searching pg_constraint once per query gets kind of expensive too: testing says that as much as half the runtime of a trivial query such as "SELECT 0::domaintype" went into that. To fix this, delegate the responsibility for tracking a domain's constraints to the typcache, which has the infrastructure needed to detect syscache invalidation events that signal possible changes. This not only removes unnecessary repeat reads of pg_constraint, but ensures that we never apply stale constraint data: whatever we use is the current data according to syscache rules. Unfortunately, the current configuration of the system catalogs means we have to flush cached domain-constraint data whenever either pg_type or pg_constraint changes, which happens rather a lot (eg, creation or deletion of a temp table will do it). It might be worth rearranging things to split pg_constraint into two catalogs, of which the domain constraint one would probably be very low-traffic. That's a job for another patch though, and in any case this patch should improve matters materially even with that handicap. This patch makes use of the recently-added memory context reset callback feature to manage the lifespan of domain constraint caches, so that we don't risk deleting a cache that might be in the midst of evaluation. Although this is a bug fix as well as a performance improvement, no back-patch. There haven't been many if any field complaints about stale domain constraint checks, so it doesn't seem worth taking the risk of modifying data structures as basic as MemoryContexts in back branches. http://git.postgresql.org/pg/commitdiff/8abb3cda0ddc00a0ab98977a1633a95b97068d4e Álvaro Herrera pushed: - Fix stupid merge errors in previous commit. Brown paper bag installed permanently. http://git.postgresql.org/pg/commitdiff/d1712d01d01d2c14355fad497fa7a6ae6e33694f - Support more commands in event triggers. COMMENT, SECURITY LABEL, and GRANT/REVOKE now also fire ddl_command_start and ddl_command_end event triggers, when they operate on database-local objects. Reviewed-By: Michael Paquier, Andres Freund, Stephen Frost http://git.postgresql.org/pg/commitdiff/296f3a6053844089bc533630fffafaba8f016384 - Fix table_rewrite event trigger for ALTER TYPE/SET DATA TYPE CASCADE. When a composite type being used in a typed table is modified by way of ALTER TYPE, a table rewrite occurs appearing to come from ALTER TYPE. The existing event_trigger.c code was unable to cope with that and raised a spurious error. The fix is just to accept that command tag for the event, and document this properly. Noted while fooling with deparsing of DDL commands. This appears to be an oversight in commit 618c9430a. Thanks to Mark Wong for documentation wording help. http://git.postgresql.org/pg/commitdiff/3f190f67eb45ae61d696fbce8ab48d246a12f709 - Make CREATE OR REPLACE VIEW internally more consistent. The way that columns are added to a view is by calling AlterTableInternal with special subtype AT_AddColumnToView; but that subtype is changed to AT_AddColumnRecurse by ATPrepAddColumn. This has no visible effect in the current code, since views cannot have inheritance children (thus the recursion step is a no-op) and adding a column to a view is executed identically to doing it to a table; but it does make a difference for future event trigger code keeping track of commands, because the current situation leads to confusing the case with a normal ALTER TABLE ADD COLUMN. Fix the problem by passing a flag to ATPrepAddColumn to prevent it from changing the command subtype. The event trigger code can then properly ignore the subcommand. (We could remove the call to ATPrepAddColumn, since views are never typed, and there is never a need for recursion, which are the two conditions that are checked by ATPrepAddColumn; but it seems more future-proof to keep the call in place.) http://git.postgresql.org/pg/commitdiff/fbef4342a86522c98cd605891ad8c1145a61d191 - Fix a couple of trivial issues in jsonb.c. Typo "aggreagate" appeared three times, and the return value of function JsonbIteratorNext() was being assigned to an int variable in a bunch of places. http://git.postgresql.org/pg/commitdiff/654809e770ce270c0bb9de726c5df1ab193d60f0 - Fix intermittent failure in event_trigger test. As evidenced by measles in buildfarm. Pointed out by Tom Lane. http://git.postgresql.org/pg/commitdiff/e059e02e43cd825616192d010e9e638a96ad4717 Peter Eisentraut pushed: - Fix invalid DocBook XML http://git.postgresql.org/pg/commitdiff/b007bee1f6962ad1007056f64b9eb2e505fa6806 - Error when creating names too long for tar format The tar format (at least the version we are using), does not support file names or symlink targets longer than 99 bytes. Until now, the tar creation code would silently truncate any names that are too long. (Its original application was pg_dump, where this never happens.) This creates problems when running base backups over the replication protocol. The most important problem is when a tablespace path is longer than 99 bytes, which will result in a truncated tablespace path being backed up. Less importantly, the basebackup protocol also promises to back up any other files it happens to find in the data directory, which would also lead to file name truncation if someone put a file with a long name in there. Now both of these cases result in an error during the backup. Add tests that fail when a too-long file name or symlink is attempted to be backed up. Reviewed-by: Robert Haas <robertmh...@gmail.com> http://git.postgresql.org/pg/commitdiff/23a78352c0a0dc21d6120bd868f0b2d07395b537 Michael Meskes pushed: - Remove null-pointer checks that are not needed. If a pointer is guaranteed to carry information there is no need to check for NULL again. Patch by Michael Paquier. http://git.postgresql.org/pg/commitdiff/8794bf1ca164e1be1554197b46c9ffc62d162fb8 Stephen Frost pushed: - Add locking clause for SB views for update/delete. In expand_security_qual(), we were handling locking correctly when a PlanRowMark existed, but not when we were working with the target relation (which doesn't have any PlanRowMarks, but the subquery created for the security barrier quals still needs to lock the rows under it). Noted by Etsuro Fujita when working with the Postgres FDW, which wasn't properly issuing a SELECT ... FOR UPDATE to the remote side under a DELETE. Back-patch to 9.4 where updatable security barrier views were introduced. Per discussion with Etsuro Fujita and Dean Rasheed. http://git.postgresql.org/pg/commitdiff/6f9bd50eabb0a4960e94c83dac8855771c9f340d - Add hasRowSecurity to copyfuncs/outfuncs. The RLS patch added a hasRowSecurity field to PlannerGlobal and PlannedStmt but didn't update nodes/copyfuncs.c and nodes/outfuncs.c to reflect those additional fields. Correct that by adding entries to the appropriate functions for those fields. Pointed out by Robert Haas. http://git.postgresql.org/pg/commitdiff/62a4a1af5d1d84f0023bc3816c204191b0f4f49f - Fix targetRelation initializiation in prepsecurity. In 6f9bd50eabb0a4960e94c83dac8855771c9f340d, we modified expand_security_quals() to tell expand_security_qual() about when the current RTE was the targetRelation. Unfortunately, that commit initialized the targetRelation variable used outside of the loop over the RTEs instead of at the start of it. This patch moves the variable and the initialization of it into the loop, where it should have been to begin with. Pointed out by Dean Rasheed. Back-patch to 9.4 as the original commit was. http://git.postgresql.org/pg/commitdiff/ee4ddcb38a0abfdb8f7302bbc332a1cb92888ed1 Noah Misch pushed: - Free SQLSTATE and SQLERRM no earlier than other PL/pgSQL variables. "RETURN SQLERRM" prompted plpgsql_exec_function() to read from freed memory. Back-patch to 9.0 (all supported versions). Little code ran between the premature free and the read, so non-assert builds are unlikely to witness user-visible consequences. http://git.postgresql.org/pg/commitdiff/f5ef00aed4c39645716cabb2e4cf1ef3598fcde7 - Unlink static libraries before rebuilding them. When the library already exists in the build directory, "ar" preserves members not named on its command line. This mattered when, for example, a "configure" rerun dropped a file from $(LIBOBJS). libpgport carried the obsolete member until "make clean". Back-patch to 9.0 (all supported versions). http://git.postgresql.org/pg/commitdiff/424793fa5dc631254f69d5ee8d7d7d6de2976f60 - Add transform functions for AT TIME ZONE. This makes "ALTER TABLE tabname ALTER tscol TYPE ... USING tscol AT TIME ZONE 'UTC'" skip rewriting the table when altering from "timestamp" to "timestamptz" or vice versa. While it would be nicer still to optimize this in the absence of the USING clause given timezone==UTC, transform functions must consult IMMUTABLE facts only. http://git.postgresql.org/pg/commitdiff/b8a18ad4850ea5ad7884aa6ab731fd392e73b4ad Andrew Dunstan pushed: - Render infinite date/timestamps as 'infinity' for json/jsonb. Commit ab14a73a6c raised an error in these cases and later the behaviour was copied to jsonb. This is what the XML code, which we then adopted, does, as the XSD types don't accept infinite values. However, json dates and timestamps are just strings as far as json is concerned, so there is no reason not to render these values as 'infinity'. The json portion of this is backpatched to 9.4 where the behaviour was introduced. The jsonb portion only affects the development branch. Per gripe on pgsql-general. http://git.postgresql.org/pg/commitdiff/bda76c1c8cfb1d11751ba6be88f0242850481733 == Rejected Patches (for now) == No one was disappointed this week :-) == Pending Patches == Corey Huinker sent in another revision of a patch to add polymorphic functions to dblink. Tom Lane sent in two more revisions of a patch to make operator precedent standards compliant and sane. Michael Paquier sent in two more revisions of a patch to enforce creation of input and output paths in pg_regress, and add regress_dynamic as a test module. David Steele sent in two more revisions of a patch to add pg_audit as an extension. Álvaro Herrera sent in a patch to remove the OBJECT_ATTRIBUTE symbol. Peter Eisentraut sent in another revision of a patch to add logical decoding support for ON CONFLICT UPDATE. Andres Freund sent in a patch to reconsider when to flush WAL and wait for syncrep while committing. Rahila Syed sent in three more revisions of a patch to compress full-page writes. Álvaro Herrera and David Fetter traded patches to fix a bug in psql's handling of connect strings and URIs in psql's \connect. Tomas Vondra sent in another revision of a patch to separate logical from physical column ordering. Michael Paquier and Stephen Frost traded patches to fix a dependency issue in pg_dump which mis-ordered tables in extensions. Kyotaro HORIGUCHI sent in another revision of a patch to ensure that pg_basebackup sends feedback regularly, even under heavy loads. Tom Lane sent in a patch to ensure that NOT LIKE, etc., have reasonable precedence. Andreas Karlsson sent in a patch to fix some autoconf deprecation warnings. Amit Langote sent in two revisions of a patch to implement native partitioning. Álvaro Herrera sent in two flocks of patches for deparsing utility commands. Alexander Korotkov sent in another revision of a patch to add KNN-GiST with recheck. Michael Paquier sent in a patch to add NULL-pointer check and incorrect comment for pstate in addRangeTableEntry. Fabien COELHO sent in two more revisions of a patch to add more tests on event triggers. Tom Lane sent in another revision of a patch to manipulate complex types as non-contiguous structures in-memory. Fabrízio de Royes Mello sent in a patch to add CINE for ALTER TABLE ... ADD COLUMN. Kyotaro HORIGUCHI sent in another revision of a patch to add new OID alias type regrole. Tom Lane sent in a patch to make MemoryContextReset delete children. Tom Lane sent in a patch to add MemoryContext reset/delete callbacks. Haribabu Kommi sent in another revision of a patch to provide a catalog view to the pg_hba.conf file. Kyotaro HORIGUCHI and Kevin Grittner traded patches to reduce pinning in btree indexes. Corey Huinker sent in another revision of a patch to allow FETCH limited by bytes. Anastasia Lubennikova and Heikki Linnakangas traded patches to add index-only scans for GiST. Michael Paquier sent in a patch to rm static libraries before rebuilding. Stephen Frost sent in another revision of a patch to add role attributes for various operations. Tom Lane sent in a patch to cache domain constraints properly. Michael Paquier sent in a patch to move freeze parameters of VacuumStmt into a separate structure. Andrew Dunstan sent in another revision of a patch to implement mogrify and indent features for jsonb. -- Sent via pgsql-announce mailing list (pgsql-announce@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-announce
