1. 04 Mar, 2020 1 commit
  2. 03 Mar, 2020 8 commits
  3. 02 Mar, 2020 9 commits
  4. 01 Mar, 2020 2 commits
  5. 29 Feb, 2020 5 commits
    • Peter Geoghegan's avatar
      Doc: Fix pageinspect bt_page_items() example. · dba91533
      Peter Geoghegan authored
      Oversight in commit 93ee38ea.
      dba91533
    • Peter Geoghegan's avatar
      Teach pageinspect about nbtree deduplication. · 93ee38ea
      Peter Geoghegan authored
      Add a new bt_metap() column to display the metapage's allequalimage
      field.  Also add three new columns to contrib/pageinspect's
      bt_page_items() function:
      
      * Add a boolean column ("dead") that displays the LP_DEAD bit value for
      each non-pivot tuple.
      
      * Add a TID column ("htid") that displays a single heap TID value for
      each tuple.  This is the TID that is returned by BTreeTupleGetHeapTID(),
      so comparable values are shown for pivot tuples, plain non-pivot tuples,
      and posting list tuples.
      
      * Add a TID array column ("tids") that displays TIDs from each tuple's
      posting list, if any.  This works just like the "tids" column from
      pageinspect's gin_leafpage_items() function.
      
      No version bump for the pageinspect extension, since there hasn't been a
      stable Postgres release since the last version bump (the last bump was
      part of commit 58b4cb30).
      
      Author: Peter Geoghegan
      Discussion: https://postgr.es/m/CAH2-WzmSMmU2eNvY9+a4MNP+z02h6sa-uxZvN3un6jY02ZVBSw@mail.gmail.com
      93ee38ea
    • Tom Lane's avatar
      Correctly re-use hash tables in buildSubPlanHash(). · 58c47ccf
      Tom Lane authored
      Commit 356687bd omitted to remove leftover code for destroying
      a hashed subplan's hash tables, with the result that the tables
      were always rebuilt not reused; this leads to severe memory
      leakage if a hashed subplan is re-executed enough times.
      Moreover, the code for reusing the hashnulls table had a typo
      that would have made it do the wrong thing if it were reached.
      
      Looking at the code coverage report shows severe under-coverage
      of the potential callers of ResetTupleHashTable, so add some test
      cases that exercise them.
      
      Andreas Karlsson and Tom Lane, per reports from Ranier Vilela
      and Justin Pryzby.
      
      Backpatch to v11, as the faulty commit was.
      
      Discussion: https://postgr.es/m/edb62547-c453-c35b-3ed6-a069e4d6b937@proxel.se
      Discussion: https://postgr.es/m/CAEudQAo=DCebm1RXtig9OH+QivpS97sMkikt0A9qHmMUs+g6ZA@mail.gmail.com
      Discussion: https://postgr.es/m/20200210032547.GA1412@telsasoft.com
      58c47ccf
    • Tom Lane's avatar
      Remove obsolete comment. · 6afc8aef
      Tom Lane authored
      Noted while studying subplan hash issue.
      6afc8aef
    • Tom Lane's avatar
      Avoid failure if autovacuum tries to access a just-dropped temp namespace. · 80d76be5
      Tom Lane authored
      Such an access became possible when commit 246a6c8f added more
      aggressive cleanup of orphaned temp relations by autovacuum.
      Since autovacuum's snapshot might be slightly stale, it could
      attempt to access an already-dropped temp namespace, resulting in
      an assertion failure or null-pointer dereference.  (In practice,
      since we don't drop temp namespaces automatically but merely
      recycle them, this situation could only arise if a superuser does
      a manual drop of a temp namespace.  Still, that should be allowed.)
      
      The core of the bug, IMO, is that isTempNamespaceInUse and its callers
      failed to think hard about whether to treat "temp namespace isn't there"
      differently from "temp namespace isn't in use".  In hopes of forestalling
      future mistakes of the same ilk, replace that function with a new one
      checkTempNamespaceStatus, which makes the same tests but returns a
      three-way enum rather than just a bool.  isTempNamespaceInUse is gone
      entirely in HEAD; but just in case some external code is relying on it,
      keep it in the back branches, as a bug-compatible wrapper around the
      new function.
      
      Per report originally from Prabhat Kumar Sahu, investigated by Mahendra
      Singh and Michael Paquier; the final form of the patch is my fault.
      This replaces the failed fix attempt in a052f6cb.
      
      Backpatch as far as v11, as 246a6c8f was.
      
      Discussion: https://postgr.es/m/CAKYtNAr9Zq=1-ww4etHo-VCC-k120YxZy5OS01VkaLPaDbv2tg@mail.gmail.com
      80d76be5
  6. 28 Feb, 2020 5 commits
  7. 27 Feb, 2020 8 commits
  8. 26 Feb, 2020 2 commits
    • Peter Geoghegan's avatar
      Silence another compiler warning in nbtinsert.c. · 2c0797da
      Peter Geoghegan authored
      Per complaint from Álvaro Herrera.
      2c0797da
    • Tom Lane's avatar
      Suppress unnecessary RelabelType nodes in more cases. · a477bfc1
      Tom Lane authored
      eval_const_expressions sometimes produced RelabelType nodes that
      were useless because they just relabeled an expression to the same
      exposed type it already had.  This is worth avoiding because it can
      cause two equivalent expressions to not be equal(), preventing
      recognition of useful optimizations.  In the test case added here,
      an unpatched planner fails to notice that the "sqli = constant" clause
      renders a sort step unnecessary, because one code path produces an
      extra RelabelType and another doesn't.
      
      Fix by ensuring that eval_const_expressions_mutator's T_RelabelType
      case will not add in an unnecessary RelabelType.  Also save some
      code by sharing a subroutine with the effectively-equivalent cases
      for CollateExpr and CoerceToDomain.  (CollateExpr had no bug, and
      I think that the case couldn't arise with CoerceToDomain, but
      it seems prudent to do the same check for all three cases.)
      
      Back-patch to v12.  In principle this has been wrong all along,
      but I haven't seen a case where it causes visible misbehavior
      before v12, so refrain from changing stable branches unnecessarily.
      
      Per investigation of a report from Eric Gillum.
      
      Discussion: https://postgr.es/m/CAMmjdmvAZsUEskHYj=KT9sTukVVCiCSoe_PBKOXsncFeAUDPCQ@mail.gmail.com
      a477bfc1