1. 26 Jan, 2017 3 commits
    • Simon Riggs's avatar
      Reset hot standby xmin on master after restart · ec4b9750
      Simon Riggs authored
      Hot_standby_feedback could be reset by reload and worked correctly, but if
      the server was restarted rather than reloaded the xmin was not reset.
      Force reset always if hot_standby_feedback is enabled at startup.
      
      Ants Aasma, Craig Ringer
      
      Reported-by: Ants Aasma
      ec4b9750
    • Tom Lane's avatar
      Ensure that a tsquery like '!foo' matches empty tsvectors. · 9d4ca013
      Tom Lane authored
      !foo means "the tsvector does not contain foo", and therefore it should
      match an empty tsvector.  ts_match_vq() overenthusiastically supposed
      that an empty tsvector could never match any query, so it forcibly
      returned FALSE, the wrong answer.  Remove the premature optimization.
      
      Our behavior on this point was inconsistent, because while seqscans and
      GIST index searches both failed to match empty tsvectors, GIN index
      searches would find them, since GIN scans don't rely on ts_match_vq().
      That makes this certainly a bug, not a debatable definition disagreement,
      so back-patch to all supported branches.
      
      Report and diagnosis by Tom Dunstan (bug #14515); added test cases by me.
      
      Discussion: https://postgr.es/m/20170126025524.1434.97828@wrigleys.postgresql.org
      9d4ca013
    • Fujii Masao's avatar
  2. 25 Jan, 2017 14 commits
    • Peter Eisentraut's avatar
      Fix typo: pg_statistics -> pg_statistic · 5a366b4f
      Peter Eisentraut authored
      5a366b4f
    • Tom Lane's avatar
      Introduce convenience macros to hide JsonbContainer header accesses better. · f7c62462
      Tom Lane authored
      This improves readability a bit and may make future improvements easier.
      
      In passing, make sure that the JB_ROOT_IS_XXX macros deliver boolean (0/1)
      results; the previous coding was a bug hazard, though no actual bugs are
      known.
      
      Nikita Glukhov, extended a bit by me
      
      Discussion: https://postgr.es/m/9e21a39c-c1d7-b9b5-44a0-c5345a5029f6@postgrespro.ru
      f7c62462
    • Peter Eisentraut's avatar
      doc: Fix typo · 049ac809
      Peter Eisentraut authored
      049ac809
    • Peter Eisentraut's avatar
      doc: Logical replication documentation improvements · 98cc5db2
      Peter Eisentraut authored
      From: Erik Rijkers <er@xs4all.nl>
      98cc5db2
    • Peter Eisentraut's avatar
      3d9e73ea
    • Peter Eisentraut's avatar
      Close replication connection when slot creation errors · 65df150a
      Peter Eisentraut authored
      From: Petr Jelinek <pjmodos@pjmodos.net>
      65df150a
    • Tom Lane's avatar
      Remove vestigial resolveUnknown arguments from transformSortClause etc. · aebeb479
      Tom Lane authored
      There's really no situation where we don't want these unknown-to-text
      conversions to happen.  The alternative is failure anyway, and the one
      caller that was passing "false" did so only because it expected the
      case could not arise.  Might as well simplify the code.
      
      Discussion: https://postgr.es/m/CAH2L28uwwbL9HUM-WR=hromW1Cvamkn7O-g8fPY2m=_7muJ0oA@mail.gmail.com
      aebeb479
    • Peter Eisentraut's avatar
      doc: Fix typo · 87ecf2d1
      Peter Eisentraut authored
      87ecf2d1
    • Tom Lane's avatar
      Make UNKNOWN into an actual pseudo-type. · d8d32d9a
      Tom Lane authored
      Previously, type "unknown" was labeled as a base type in pg_type, which
      perhaps had some sense to it because you were allowed to create tables with
      unknown-type columns.  But now that we don't allow that, it makes more
      sense to label it a pseudo-type.  This has the additional effects of
      forbidding use of "unknown" as a domain base type, cast source or target
      type, PL function argument or result type, or plpgsql local variable type;
      all of which seem like good holes to plug.
      
      Discussion: https://postgr.es/m/CAH2L28uwwbL9HUM-WR=hromW1Cvamkn7O-g8fPY2m=_7muJ0oA@mail.gmail.com
      d8d32d9a
    • Tom Lane's avatar
      Change unknown-type literals to type text in SELECT and RETURNING lists. · 1e7c4bb0
      Tom Lane authored
      Previously, we left such literals alone if the query or subquery had
      no properties forcing a type decision to be made (such as an ORDER BY or
      DISTINCT clause using that output column).  This meant that "unknown" could
      be an exposed output column type, which has never been a great idea because
      it could result in strange failures later on.  For example, an outer query
      that tried to do any operations on an unknown-type subquery output would
      generally fail with some weird error like "failed to find conversion
      function from unknown to text" or "could not determine which collation to
      use for string comparison".  Also, if the case occurred in a CREATE VIEW's
      query then the view would have an unknown-type column, causing similar
      failures in queries trying to use the view.
      
      To fix, at the tail end of parse analysis of a query, forcibly convert any
      remaining "unknown" literals in its SELECT or RETURNING list to type text.
      However, provide a switch to suppress that, and use it in the cases of
      SELECT inside a set operation or INSERT command.  In those cases we already
      had type resolution rules that make use of context information from outside
      the subquery proper, and we don't want to change that behavior.
      
      Also, change creation of an unknown-type column in a relation from a
      warning to a hard error.  The error should be unreachable now in CREATE
      VIEW or CREATE MATVIEW, but it's still possible to explicitly say "unknown"
      in CREATE TABLE or CREATE (composite) TYPE.  We want to forbid that because
      it's nothing but a foot-gun.
      
      This change creates a pg_upgrade failure case: a matview that contains an
      unknown-type column can't be pg_upgraded, because reparsing the matview's
      defining query will now decide that the column is of type text, which
      doesn't match the cstring-like storage that the old materialized column
      would actually have.  Add a checking pass to detect that.  While at it,
      we can detect tables or composite types that would fail, essentially
      for free.  Those would fail safely anyway later on, but we might as
      well fail earlier.
      
      This patch is by me, but it owes something to previous investigations
      by Rahila Syed.  Also thanks to Ashutosh Bapat and Michael Paquier for
      review.
      
      Discussion: https://postgr.es/m/CAH2L28uwwbL9HUM-WR=hromW1Cvamkn7O-g8fPY2m=_7muJ0oA@mail.gmail.com
      1e7c4bb0
    • Peter Eisentraut's avatar
      doc: Update ALTER SEQUENCE documentation to match · 123f03ba
      Peter Eisentraut authored
      Update documentation to match change in
      0bc1207a.
      123f03ba
    • Tom Lane's avatar
      Improve speed of contrib/postgres_fdw regression tests. · aa7f593b
      Tom Lane authored
      Commit 7012b132 added some tests that consumed an excessive amount of
      time, more than tripling the time needed for "make installcheck" for this
      module.  Add filter conditions to reduce the number of rows scanned,
      bringing the runtime down to within hailing distance of what it was before.
      
      Jeevan Chalke and Ashutosh Bapat, per a gripe from me
      
      Discussion: https://postgr.es/m/16565.1478104765@sss.pgh.pa.us
      aa7f593b
    • Robert Haas's avatar
      Be more aggressive in avoiding tuple conversion. · 3838074f
      Robert Haas authored
      According to the comments in tupconvert.c, it's necessary to perform
      tuple conversion when either table has OIDs, and this was previously
      checked by ensuring that the tdtypeid value matched between the tables
      in question.  However, that's overly stringent: we have access to
      tdhasoid and can test directly whether OIDs are present, which lets us
      avoid conversion in cases where the type OIDs are different but the
      tuple descriptors are entirely the same (and neither has OIDs).  This
      is useful to the partitioning code, which can thereby avoid converting
      tuples when inserting into a partition whose columns appear in the
      same order as the parent columns, the normal case.  It's possible
      for the tuple routing code to avoid some additional overhead in this
      case as well, so do that, too.
      
      It's not clear whether it would be OK to skip this when both tables
      have OIDs: do callers count on this to build a new tuple (losing the
      previous OID) in such instances?  Until we figure it out, leave the
      behavior in that case alone.
      
      Amit Langote, reviewed by me.
      3838074f
    • Tom Lane's avatar
      Use non-conflicting table names in new regression test case. · 7fa7bf18
      Tom Lane authored
      Commit 587cda35 added a test to updatable_views.sql that created
      tables named the same as tables used by the concurrent inherit.sql
      script.  Unsurprisingly, this results in random failures.
      Pick different names.
      
      Per buildfarm.
      7fa7bf18
  3. 24 Jan, 2017 15 commits
  4. 23 Jan, 2017 8 commits