1. 02 Nov, 2016 3 commits
  2. 01 Nov, 2016 4 commits
  3. 31 Oct, 2016 1 commit
  4. 30 Oct, 2016 5 commits
    • Tatsuo Ishii's avatar
      Fix typo in sources.sgml. · 36d154ec
      Tatsuo Ishii authored
      Per Shinichi Matsuda.
      36d154ec
    • Tom Lane's avatar
      Fix nasty performance problem in tsquery_rewrite(). · 5ec81ace
      Tom Lane authored
      tsquery_rewrite() tries to find matches to subsets of AND/OR conditions;
      for example, in the query 'a | b | c' the substitution subquery 'a | c'
      should match and lead to replacement of the first and third items.
      That's fine, but the matching algorithm apparently takes about O(2^N)
      for an N-clause query (I say "apparently" because the code is also both
      unintelligible and uncommented).  We could probably do better than that
      even without any extra assumptions --- but actually, we know that the
      subclauses are sorted, indeed are depending on that elsewhere in this very
      same function.  So we can just scan the two lists a single time to detect
      matches, as though we were doing a merge join.
      
      Also do a re-flattening call (QTNTernary()) in tsquery_rewrite_query, just
      to make sure that the tree fits the expectations of the next search cycle.
      I didn't try to devise a test case for this, but I'm pretty sure that the
      oversight could have led to failure to match in some cases where a match
      would be expected.
      
      Improve comments, and also stick a CHECK_FOR_INTERRUPTS into
      dofindsubquery, just in case it's still too slow for somebody.
      
      Per report from Andreas Seltenreich.  Back-patch to all supported branches.
      
      Discussion: <8760oasf2y.fsf@credativ.de>
      5ec81ace
    • Tom Lane's avatar
      Fix bogus tree-flattening logic in QTNTernary(). · 24ebc444
      Tom Lane authored
      QTNTernary() contains logic to flatten, eg, '(a & b) & c' into 'a & b & c',
      which is all well and good, but it tries to do that to NOT nodes as well,
      so that '!!a' gets changed to '!a'.  Explicitly restrict the conversion to
      be done only on AND and OR nodes, and add a test case illustrating the bug.
      
      In passing, provide some comments for the sadly naked functions in
      tsquery_util.c, and simplify some baroque logic in QTNFree(), which
      I think may have been leaking some items it intended to free.
      
      Noted while investigating a complaint from Andreas Seltenreich.
      Back-patch to all supported versions.
      24ebc444
    • Tom Lane's avatar
      Improve speed of aggregates that use array_append as transition function. · 9a00f03e
      Tom Lane authored
      In the previous coding, if an aggregate's transition function returned an
      expanded array, nodeAgg.c and nodeWindowAgg.c would always copy it and thus
      force it into the flat representation.  This led to ping-ponging between
      flat and expanded formats, which costs a lot.  For an aggregate using
      array_append as transition function, I measured about a 15X slowdown
      compared to the pre-9.5 code, when working on simple int[] arrays.
      Of course, the old code was already O(N^2) in this usage due to copying
      flat arrays all the time, but it wasn't quite this inefficient.
      
      To fix, teach nodeAgg.c and nodeWindowAgg.c to allow expanded transition
      values without copying, so long as the transition function takes care to
      return the transition value already properly parented under the aggcontext.
      That puts a bit of extra responsibility on the transition function, but
      doing it this way allows us to not need any extra logic in the fast path
      of advance_transition_function (ie, with a pass-by-value transition value,
      or with a modified-in-place pass-by-reference value).  We already know
      that that's a hot spot so I'm loath to add any cycles at all there.  Also,
      while only array_append currently knows how to follow this convention,
      this solution allows other transition functions to opt-in without needing
      to have a whitelist in the core aggregation code.
      
      (The reason we would need a whitelist is that currently, if you pass a
      R/W expanded-object pointer to an arbitrary function, it's allowed to do
      anything with it including deleting it; that breaks the core agg code's
      assumption that it should free discarded values.  Returning a value under
      aggcontext is the transition function's signal that it knows it is an
      aggregate transition function and will play nice.  Possibly the API rules
      for expanded objects should be refined, but that would not be a
      back-patchable change.)
      
      With this fix, an aggregate using array_append is no longer O(N^2), so it's
      much faster than pre-9.5 code rather than much slower.  It's still a bit
      slower than the bespoke infrastructure for array_agg, but the differential
      seems to be only about 10%-20% rather than orders of magnitude.
      
      Discussion: <6315.1477677885@sss.pgh.pa.us>
      9a00f03e
    • Magnus Hagander's avatar
      Fix memory leak in tar file padding · a775406e
      Magnus Hagander authored
      Spotted by Coverity, patch by Michael Paquier
      a775406e
  5. 28 Oct, 2016 3 commits
    • Robert Haas's avatar
      pgstattuple: Don't take heavyweight locks when examining a hash index. · d4b5d4ca
      Robert Haas authored
      It's currently necessary to take a heavyweight lock when scanning a
      hash bucket, but pgstattuple only examines individual pages, so it
      doesn't need to do this.  If, for some hypothetical reason, it did
      need to do any heavyweight locking here, this logic would probably
      still be incorrect, because most of the locks that it is taking are
      meaningless.  Only a heavyweight lock on a primary bucket page has any
      meaning, but this takes heavyweight locks on all pages regardless of
      function - and in particular overflow pages, where you might imagine
      that we'd want to lock the primary bucket page if we needed to lock
      anything at all.
      
      This is arguably a bug that has existed since this code was added in
      commit dab42382, but I'm not going to
      bother back-patching it because in most cases the only consequence is
      that running pgstattuple() on a hash index is a little slower than it
      otherwise might be, which is no big deal.
      
      Extracted from a vastly larger patch by Amit Kapila which heavyweight
      locking for hash indexes entirely; analysis of why this can be done
      independently of the rest by me.
      d4b5d4ca
    • Robert Haas's avatar
      Fix leftover reference to background writer performing checkpoints. · 33839b5f
      Robert Haas authored
      This was changed in PostgreSQL 9.2, but somehow this comment never
      got updated.
      33839b5f
    • Peter Eisentraut's avatar
      doc: Small style improvements · a94b7035
      Peter Eisentraut authored
      a94b7035
  6. 27 Oct, 2016 7 commits
    • Peter Eisentraut's avatar
      Remove invitation to report a bug about unknown encoding · ce4dc970
      Peter Eisentraut authored
      The error message when we couldn't determine the encoding from a locale
      said to report a bug about that.  That might have been appropriate when
      this code was first added, but by now this works pretty solidly and any
      encodings we don't recognize we probably just don't support.  We still
      print the warning, but no longer invite the bug report.
      ce4dc970
    • Peter Eisentraut's avatar
      Add function name to PyArg_ParseTuple() · eaed88ce
      Peter Eisentraut authored
      This causes the supplied function name to appear in any error message,
      making the error message friendlier and relieving us from having to
      provide our own in some cases.
      eaed88ce
    • Peter Eisentraut's avatar
      Format PL/Python module contents test vertically · 84d457ed
      Peter Eisentraut authored
      It makes it readable again and makes merges more manageable.
      84d457ed
    • Robert Haas's avatar
      If the stats collector dies during Hot Standby, restart it. · 4f714b2f
      Robert Haas authored
      This bug exists as far back as 9.0, when Hot Standby was introduced,
      so back-patch to all supported branches.
      
      Report and patch by Takayuki Tsunakawa, reviewed by Michael Paquier
      and Kuntal Ghosh.
      4f714b2f
    • Robert Haas's avatar
      Fix possible pg_basebackup failure on standby with "include WAL". · f267c1c2
      Robert Haas authored
      If a restartpoint flushed no dirty buffers, it could fail to update
      the minimum recovery point, leading to a minimum recovery point prior
      to the starting REDO location.  perform_base_backup() would interpret
      that as meaning that no WAL files at all needed to be included in the
      backup, failing an internal sanity check.  To fix, have restartpoints
      always update the minimum recovery point to just after the checkpoint
      record itself, so that the file (or files) containing the checkpoint
      record will always be included in the backup.
      
      Code by Amit Kapila, per a design suggestion by me, with some
      additional work on the code comment by me.  Test case by Michael
      Paquier.  Report by Kyotaro Horiguchi.
      f267c1c2
    • Peter Eisentraut's avatar
      Avoid using a C++ keyword in header file · c32fe432
      Peter Eisentraut authored
      per cpluspluscheck
      c32fe432
    • Bruce Momjian's avatar
      Properly indent postgresql.conf comments to align · 586a46c2
      Bruce Momjian authored
      A few comments were misaligned.
      586a46c2
  7. 26 Oct, 2016 12 commits
    • Tom Lane's avatar
      Fix incorrect trigger-property updating in ALTER CONSTRAINT. · a522fc3d
      Tom Lane authored
      The code to change the deferrability properties of a foreign-key constraint
      updated all the associated triggers to match; but a moment's examination of
      the code that creates those triggers in the first place shows that only
      some of them should track the constraint's deferrability properties.  This
      leads to odd failures in subsequent exercise of the foreign key, as the
      triggers are fired at the wrong times.  Fix that, and add a regression test
      comparing the trigger properties produced by ALTER CONSTRAINT with those
      you get by creating the constraint as-intended to begin with.
      
      Per report from James Parks.  Back-patch to 9.4 where this ALTER
      functionality was introduced.
      
      Report: <CAJ3Xv+jzJ8iNNUcp4RKW8b6Qp1xVAxHwSXVpjBNygjKxcVuE9w@mail.gmail.com>
      a522fc3d
    • Tom Lane's avatar
      Fix not-HAVE_SYMLINK code in zic.c. · 19b2094d
      Tom Lane authored
      I broke this in commit f3094920.  Apparently it's dead code anyway,
      at least as far as our buildfarm is concerned (and the upstream IANA
      code doesn't worry at all about symlink() not being present).
      But as long as the rest of our code is willing to guard against not
      having symlink(), this should too.  Noted while investigating a
      tangentially-related complaint from Sandeep Thakkar.
      
      Back-patch to keep branches in sync.
      19b2094d
    • Tom Lane's avatar
      Doc: improve documentation about inheritance. · 162477a6
      Tom Lane authored
      Clarify documentation about inheritance of check constraints, in
      particular mentioning the NO INHERIT option, which didn't exist when
      this text was written.
      
      Document that in an inherited query, the applicable row security policies
      are those of the explicitly-named table, not its children.  This is the
      intended behavior (per off-list discussion with Stephen Frost), and there
      are regression tests for it, but it wasn't documented anywhere user-facing
      as far as I could find.
      
      Do a bit of wordsmithing on the description of inherited access-privilege
      checks.
      
      Back-patch to 9.5 where RLS was added.
      162477a6
    • Tom Lane's avatar
      Suppress unused-variable warning in non-assert builds. · 8529686c
      Tom Lane authored
      Introduced in commit 7012b132.
      
      Kyotaro Horiguchi
      8529686c
    • Heikki Linnakangas's avatar
      Remove platform-dependent PL/python test case. · 8eb6337f
      Heikki Linnakangas authored
      Turns out that the output format of Python Decimal isn't totally platform-
      independent either. There are other tests for multi-dimensional arrays,
      so rather than try to fix this test case, just remove it.
      
      Per buildfarm member prairiedog.
      8eb6337f
    • Heikki Linnakangas's avatar
      Only treat Python Lists as array dimensions. · cfd9c87a
      Heikki Linnakangas authored
      Instead of treating all python sequence types as array dimensions, except
      for tuples and various kinds of strings, only treat Python lists as
      dimensions. The PyBytes_Check() function used previously is only available
      on Python 2.6 and newer, and it was a bit fiddly anyway. The list of
      exceptions would require adjustment if Python got a new kind of a sequence
      similar to bytes/unicodes/strings, so only checking for Lists seems more
      future-proof. The documentation only mentioned using Lists, so this is
      closer to what was documented, anyway.
      
      This should fix the buildfarm failures on systems building with Python 2.5,
      although I don't have Python 2.5 installed myself to test with.
      cfd9c87a
    • Heikki Linnakangas's avatar
      Avoid using platform-dependent floats in test case. · 73c8e850
      Heikki Linnakangas authored
      The number of decimals printed for floats varied in this test case, as
      noted by several buildfarm members. There's nothing special about floats
      and arrays in the code being tested, so replace the floats with numerics to
      make the output platform-independent.
      73c8e850
    • Heikki Linnakangas's avatar
      Fix regression test to also work with Python 2. · e131ba4f
      Heikki Linnakangas authored
      Per buildfarm.
      e131ba4f
    • Heikki Linnakangas's avatar
      Fix typos in comments. · 56f39009
      Heikki Linnakangas authored
      Vinayak Pokale
      56f39009
    • Heikki Linnakangas's avatar
      Fix typo in comment. · 8a2f08fb
      Heikki Linnakangas authored
      Daniel Gustafsson
      8a2f08fb
    • Heikki Linnakangas's avatar
      Give a hint, when [] is incorrectly used for a composite type in array. · 510e1b8e
      Heikki Linnakangas authored
      That used to be accepted, so let's try to give a hint to users on why
      their PL/python functions no longer work.
      
      Reviewed by Pavel Stehule.
      
      Discussion: <CAH38_tmbqwaUyKs9yagyRra=SMaT45FPBxk1pmTYcM0TyXGG7Q@mail.gmail.com>
      510e1b8e
    • Heikki Linnakangas's avatar
      Support multi-dimensional arrays in PL/python. · 94aceed3
      Heikki Linnakangas authored
      Multi-dimensional arrays can now be used as arguments to a PL/python function
      (used to throw an error), and they can be returned as nested Python lists.
      
      This makes a backwards-incompatible change to the handling of composite
      types in arrays. Previously, you could return an array of composite types
      as "[[col1, col2], [col1, col2]]", but now that is interpreted as a two-
      dimensional array. Composite types in arrays must now be returned as
      Python tuples, not lists, to resolve the ambiguity. I.e. "[(col1, col2),
      (col1, col2)]".
      
      To avoid breaking backwards-compatibility, when not necessary, () is still
      accepted for arrays at the top-level, but it is always treated as a
      single-dimensional array. Likewise, [] is still accepted for composite types,
      when they are not in an array. Update the documentation to recommend using []
      for arrays, and () for composite types, with a mention that those other things
      are also accepted in some contexts.
      
      This needs to be mentioned in the release notes.
      
      Alexey Grishchenko, Dave Cramer and me. Reviewed by Pavel Stehule.
      
      Discussion: <CAH38_tmbqwaUyKs9yagyRra=SMaT45FPBxk1pmTYcM0TyXGG7Q@mail.gmail.com>
      94aceed3
  8. 25 Oct, 2016 5 commits