== 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

Reply via email to