1. 20 May, 2018 2 commits
  2. 19 May, 2018 4 commits
  3. 18 May, 2018 10 commits
  4. 17 May, 2018 4 commits
  5. 16 May, 2018 5 commits
    • Tom Lane's avatar
      Detoast plpgsql variables if they might live across a transaction boundary. · 2efc9241
      Tom Lane authored
      Up to now, it's been safe for plpgsql to store TOAST pointers in its
      variables because the ActiveSnapshot for whatever query called the plpgsql
      function will surely protect such TOAST values from being vacuumed away,
      even if the owning table rows are committed dead.  With the introduction of
      procedures, that assumption is no longer good in "non atomic" executions
      of plpgsql code.  We adopt the slightly brute-force solution of detoasting
      all TOAST pointers at the time they are stored into variables, if we're in
      a non-atomic context, just in case the owning row goes away.
      
      Some care is needed to avoid long-term memory leaks, since plpgsql tends
      to run with CurrentMemoryContext pointing to its call-lifespan context,
      but we shouldn't assume that no memory is leaked by heap_tuple_fetch_attr.
      In plpgsql proper, we can do the detoasting work in the "eval_mcontext".
      
      Most of the code thrashing here is due to the need to add this capability
      to expandedrecord.c as well as plpgsql proper.  In expandedrecord.c,
      we can't assume that the caller's context is short-lived, so make use of
      the short-term sub-context that was already invented for checking domain
      constraints.  In view of this repurposing, it seems good to rename that
      variable and associated code from "domain_check_cxt" to "short_term_cxt".
      
      Peter Eisentraut and Tom Lane
      
      Discussion: https://postgr.es/m/5AC06865.9050005@anastigmatix.net
      2efc9241
    • Tom Lane's avatar
      Fix misprocessing of equivalence classes involving record_eq(). · a11b3bd3
      Tom Lane authored
      canonicalize_ec_expression() is supposed to agree with coerce_type() as to
      whether a RelabelType should be inserted to make a subexpression be valid
      input for the operators of a given opclass.  However, it did the wrong
      thing with named-composite-type inputs to record_eq(): it put in a
      RelabelType to RECORDOID, which the parser doesn't.  In some cases this was
      harmless because all code paths involving a particular equivalence class
      did the same thing, but in other cases this would result in failing to
      recognize a composite-type expression as being a member of an equivalence
      class that it actually is a member of.  The most obvious bad effect was to
      fail to recognize that an index on a composite column could provide the
      sort order needed for a mergejoin on that column, as reported by Teodor
      Sigaev.  I think there might be other, subtler, cases that result in
      misoptimization.  It also seems possible that an unwanted RelabelType
      would sometimes get into an emitted plan --- but because record_eq and
      friends don't examine the declared type of their input expressions, that
      would not create any visible problems.
      
      To fix, just treat RECORDOID as if it were a polymorphic type, which in
      some sense it is.  We might want to consider formalizing that a bit more
      someday, but for the moment this seems to be the only place where an
      IsPolymorphicType() test ought to include RECORDOID as well.
      
      This has been broken for a long time, so back-patch to all supported
      branches.
      
      Discussion: https://postgr.es/m/a6b22369-e3bf-4d49-f59d-0c41d3551e81@sigaev.ru
      a11b3bd3
    • Robert Haas's avatar
      Pass the correct PlannerInfo to PlanForeignModify/PlanDirectModify. · 7fc7dac1
      Robert Haas authored
      Previously, we passed the toplevel PlannerInfo, but we actually want
      to pass the relevant subroot.  One problem with passing the toplevel
      PlannerInfo is that the FDW which wants to push down an UPDATE or
      DELETE against a join won't find the relevant joinrel there.
      As of commit 1bc0100d, postgres_fdw
      tries to do exactly this and can be made to fail an assertion as a
      result.
      
      It's possible that this should be regarded as a bug fix and
      back-patched to earlier releases, but for lack of a test case that
      fails in earlier releases, no back-patch for now.
      
      Etsuro Fujita, reviewed by Amit Langote.
      
      Discussion: http://postgr.es/m/5AF43E02.30000@lab.ntt.co.jp
      7fc7dac1
    • Robert Haas's avatar
      Improve comment in get_partition_dispatch_recurse. · 09b12d52
      Robert Haas authored
      David Rowley, reviewed by Amit Langote, and revised a bit by me.
      
      Discussion: http://postgr.es/m/CAKJS1f9yyimYyFzbHM4EwE+tkj4jvrHqSH0H4S4Kbas=UFpc9Q@mail.gmail.com
      09b12d52
    • Bruce Momjian's avatar
      docs: add space in PG 11 release notes, huge/large · 6bd1b4c3
      Bruce Momjian authored
      Reported-by: Tatsuo Ishii
      6bd1b4c3
  6. 15 May, 2018 5 commits
  7. 14 May, 2018 5 commits
  8. 13 May, 2018 1 commit
  9. 12 May, 2018 1 commit
  10. 11 May, 2018 3 commits