1. 29 Jan, 2020 6 commits
  2. 28 Jan, 2020 7 commits
  3. 27 Jan, 2020 5 commits
  4. 26 Jan, 2020 4 commits
    • Tom Lane's avatar
      Fix EXPLAIN (SETTINGS) to follow policy about when to print empty fields. · 3ec20c70
      Tom Lane authored
      In non-TEXT output formats, the "Settings" field should appear when
      requested, even if it would be empty.
      
      Also, get rid of the premature optimization of counting all the
      GUC_EXPLAIN variables at startup.  Since there was no provision for
      adjusting that count later, all it'd take would be some extension marking
      a parameter as GUC_EXPLAIN to risk an assertion failure or memory stomp.
      We could make get_explain_guc_options() count those variables on-the-fly,
      or dynamically resize its array ... but TBH I do not think that making a
      transient array of pointers a bit smaller is worth any extra complication,
      especially when you consider all the other transient space EXPLAIN eats.
      So just allocate that array at the max possible size.
      
      In HEAD, also add some regression test coverage for this feature.
      
      Because of the memory-stomp hazard, back-patch to v12 where this
      feature was added.
      
      Discussion: https://postgr.es/m/19416.1580069629@sss.pgh.pa.us
      3ec20c70
    • Thomas Munro's avatar
      Refactor confusing code in _mdfd_openseg(). · f37ff034
      Thomas Munro authored
      As reported independently by a couple of people, _mdfd_openseg() is coded in a
      way that seems to imply that the segments could be opened in an order that
      isn't strictly sequential.  Even if that were true, it's also using the wrong
      comparison.  It's not an active bug, since the condition is always true anyway,
      but it's confusing, so replace it with an assertion.
      
      Author: Thomas Munro
      Reviewed-by: Andres Freund, Kyotaro Horiguchi, Noah Misch
      Discussion: https://postgr.es/m/CA%2BhUKG%2BNBw%2BuSzxF1os-SO6gUuw%3DcqO5DAybk6KnHKzgGvxhxA%40mail.gmail.com
      Discussion: https://postgr.es/m/20191222091930.GA1280238%40rfd.leadboat.com
      f37ff034
    • Tom Lane's avatar
      In postgres_fdw, don't try to ship MULTIEXPR updates to remote server. · 215824f9
      Tom Lane authored
      In a statement like "UPDATE remote_tab SET (x,y) = (SELECT ...)",
      we'd conclude that the statement could be directly executed remotely,
      because the sub-SELECT is in a resjunk tlist item that's not examined
      for shippability.  Currently that ends up crashing if the sub-SELECT
      contains any remote Vars.  Prevent the crash by deeming MULTIEXEC
      Params to be unshippable.
      
      This is a bit of a brute-force solution, since if the sub-SELECT
      *doesn't* contain any remote Vars, the current execution technology
      would work; but that's not a terribly common use-case for this syntax,
      I think.  In any case, we generally don't try to ship sub-SELECTs, so
      it won't surprise anybody that this doesn't end up as a remote direct
      update.  I'd be inclined to see if that general limitation can be fixed
      before worrying about this case further.
      
      Per report from Lukáš Sobotka.
      
      Back-patch to 9.6.  9.5 had MULTIEXPR, but we didn't try to perform
      remote direct updates then, so the case didn't arise anyway.
      
      Discussion: https://postgr.es/m/CAJif3k+iA_ekBB5Zw2hDBaE1wtiQa4LH4_JUXrrMGwTrH0J01Q@mail.gmail.com
      215824f9
    • Heikki Linnakangas's avatar
      Refactor XLogReadRecord(), adding XLogBeginRead() function. · 38a95731
      Heikki Linnakangas authored
      The signature of XLogReadRecord() required the caller to pass the starting
      WAL position as argument, or InvalidXLogRecPtr to continue reading at the
      end of previous record. That's slightly awkward to the callers, as most
      of them don't want to randomly jump around in the WAL stream, but start
      reading at one position and then read everything from that point onwards.
      Remove the 'RecPtr' argument and add a new function XLogBeginRead() to
      specify the starting position instead. That's more convenient for the
      callers. Also, xlogreader holds state that is reset when you change the
      starting position, so having a separate function for doing that feels like
      a more natural fit.
      
      This changes XLogFindNextRecord() function so that it doesn't reset the
      xlogreader's state to what it was before the call anymore. Instead, it
      positions the xlogreader to the found record, like XLogBeginRead().
      
      Reviewed-by: Kyotaro Horiguchi, Alvaro Herrera
      Discussion: https://www.postgresql.org/message-id/5382a7a3-debe-be31-c860-cb810c08f366%40iki.fi
      38a95731
  5. 25 Jan, 2020 2 commits
    • Tom Lane's avatar
      Clean up EXPLAIN's handling of per-worker details. · 10013684
      Tom Lane authored
      Previously, it was possible for EXPLAIN ANALYZE of a parallel query
      to produce several different "Workers" fields for a single plan node,
      because different portions of explain.c independently generated
      per-worker data and wrapped that output in separate fields.  This
      is pretty bogus, especially for the structured output formats: even
      if it's not technically illegal, most programs would have a hard time
      dealing with such data.
      
      To improve matters, add infrastructure that allows redirecting
      per-worker values into a side data structure, and then collect that
      data into a single "Workers" field after we've finished running all
      the relevant code for a given plan node.
      
      There are a few visible side-effects:
      
      * In text format, instead of something like
      
        Sort Method: external merge  Disk: 4920kB
        Worker 0:  Sort Method: external merge  Disk: 5880kB
        Worker 1:  Sort Method: external merge  Disk: 5920kB
        Buffers: shared hit=682 read=10188, temp read=1415 written=2101
        Worker 0:  actual time=130.058..130.324 rows=1324 loops=1
          Buffers: shared hit=337 read=3489, temp read=505 written=739
        Worker 1:  actual time=130.273..130.512 rows=1297 loops=1
          Buffers: shared hit=345 read=3507, temp read=505 written=744
      
      you get
      
        Sort Method: external merge  Disk: 4920kB
        Buffers: shared hit=682 read=10188, temp read=1415 written=2101
        Worker 0:  actual time=130.058..130.324 rows=1324 loops=1
          Sort Method: external merge  Disk: 5880kB
          Buffers: shared hit=337 read=3489, temp read=505 written=739
        Worker 1:  actual time=130.273..130.512 rows=1297 loops=1
          Sort Method: external merge  Disk: 5920kB
          Buffers: shared hit=345 read=3507, temp read=505 written=744
      
      * When JIT is enabled, any relevant per-worker JIT stats are attached
      to the child node of the Gather or Gather Merge node, which is where
      the other per-worker output has always been.  Previously, that info
      was attached directly to a Gather node, or missed entirely for Gather
      Merge.
      
      * A query's summary JIT data no longer includes a bogus
      "Worker Number: -1" field.
      
      A notable code-level change is that indenting for lines of text-format
      output should now be handled by calling "ExplainIndentText(es)",
      instead of hard-wiring how much space to emit.  This seems a good deal
      cleaner anyway.
      
      This patch also adds a new "explain.sql" regression test script that's
      dedicated to testing EXPLAIN.  There is more that can be done in that
      line, certainly, but for now it just adds some coverage of the XML and
      YAML output formats, which had been completely untested.
      
      Although this is surely a bug fix, it's not clear that people would
      be happy with rearranging EXPLAIN output in a minor release, so apply
      to HEAD only.
      
      Maciek Sakrejda and Tom Lane, based on an idea of Andres Freund's;
      reviewed by Georgios Kokolatos
      
      Discussion: https://postgr.es/m/CAOtHd0AvAA8CLB9Xz0wnxu1U=zJCKrr1r4QwwXi_kcQsHDVU=Q@mail.gmail.com
      10013684
    • Dean Rasheed's avatar
      Add functions gcd() and lcm() for integer and numeric types. · 13661ddd
      Dean Rasheed authored
      These compute the greatest common divisor and least common multiple of
      a pair of numbers using the Euclidean algorithm.
      
      Vik Fearing, reviewed by Fabien Coelho.
      
      Discussion: https://postgr.es/m/adbd3e0b-e3f1-5bbc-21db-03caf1cef0f7@2ndquadrant.com
      13661ddd
  6. 24 Jan, 2020 7 commits
  7. 23 Jan, 2020 6 commits
    • Tom Lane's avatar
      Add configure probe for rl_completion_suppress_quote. · c3270444
      Tom Lane authored
      I had supposed that all versions of Readline that have filename
      quoting hooks also have the rl_completion_suppress_quote variable.
      But it seems OpenBSD managed to find a version someplace that does
      not, so we'll have to expend a separate configure probe for that.
      
      (Light testing suggests that this version also lacks the bugs that
      make it necessary to frob that variable.  Hooray!)
      
      Per buildfarm.
      c3270444
    • Tom Lane's avatar
      Fix an oversight in commit 4c70098f. · 9a3a75cb
      Tom Lane authored
      I had supposed that the from_char_seq_search() call sites were
      all passing the constant arrays you'd expect them to pass ...
      but on looking closer, the one for DY format was passing the
      days[] array not days_short[].  This accidentally worked because
      the day abbreviations in English are all the same as the first
      three letters of the full day names.  However, once we took out
      the "maximum comparison length" logic, it stopped working.
      
      As penance for that oversight, add regression test cases covering
      this, as well as every other switch case in DCH_from_char() that
      was not reached according to the code coverage report.
      
      Also, fold the DCH_RM and DCH_rm cases into one --- now that
      seq_search is case independent, there's no need to pass different
      comparison arrays for those cases.
      
      Back-patch, as the previous commit was.
      9a3a75cb
    • Tom Lane's avatar
      Clean up formatting.c's logic for matching constant strings. · 4c70098f
      Tom Lane authored
      seq_search(), which is used to match input substrings to constants
      such as month and day names, had a lot of bizarre and unnecessary
      behaviors.  It was mostly possible to avert our eyes from that before,
      but we don't want to duplicate those behaviors in the upcoming patch
      to allow recognition of non-English month and day names.  So it's time
      to clean this up.  In particular:
      
      * seq_search scribbled on the input string, which is a pretty dangerous
      thing to do, especially in the badly underdocumented way it was done here.
      Fortunately the input string is a temporary copy, but that was being made
      three subroutine levels away, making it something easy to break
      accidentally.  The behavior is externally visible nonetheless, in the form
      of odd case-folding in error reports about unrecognized month/day names.
      The scribbling is evidently being done to save a few calls to pg_tolower,
      but that's such a cheap function (at least for ASCII data) that it's
      pretty pointless to worry about.  In HEAD I switched it to be
      pg_ascii_tolower to ensure it is cheap in all cases; but there are corner
      cases in Turkish where this'd change behavior, so leave it as pg_tolower
      in the back branches.
      
      * seq_search insisted on knowing the case form (all-upper, all-lower,
      or initcap) of the constant strings, so that it didn't have to case-fold
      them to perform case-insensitive comparisons.  This likewise seems like
      excessive micro-optimization, given that pg_tolower is certainly very
      cheap for ASCII data.  It seems unsafe to assume that we know the case
      form that will come out of pg_locale.c for localized month/day names, so
      it's better just to define the comparison rule as "downcase all strings
      before comparing".  (The choice between downcasing and upcasing is
      arbitrary so far as English is concerned, but it might not be in other
      locales, so follow citext's lead here.)
      
      * seq_search also had a parameter that'd cause it to report a match
      after a maximum number of characters, even if the constant string were
      longer than that.  This was not actually used because no caller passed
      a value small enough to cut off a comparison.  Replicating that behavior
      for localized month/day names seems expensive as well as useless, so
      let's get rid of that too.
      
      * from_char_seq_search used the maximum-length parameter to truncate
      the input string in error reports about not finding a matching name.
      This leads to rather confusing reports in many cases.  Worse, it is
      outright dangerous if the input string isn't all-ASCII, because we
      risk truncating the string in the middle of a multibyte character.
      That'd lead either to delivering an illegible error message to the
      client, or to encoding-conversion failures that obscure the actual
      data problem.  Get rid of that in favor of truncating at whitespace
      if any (a suggestion due to Alvaro Herrera).
      
      In addition to fixing these things, I const-ified the input string
      pointers of DCH_from_char and its subroutines, to make sure there
      aren't any other scribbling-on-input problems.
      
      The risk of generating a badly-encoded error message seems like
      enough of a bug to justify back-patching, so patch all supported
      branches.
      
      Discussion: https://postgr.es/m/29432.1579731087@sss.pgh.pa.us
      4c70098f
    • Tom Lane's avatar
      Improve psql's tab completion for filenames. · cd69ec66
      Tom Lane authored
      The Readline library contains a fair amount of knowledge about how to
      tab-complete filenames, but it turns out that that doesn't work too well
      unless we follow its expectation that we use its filename quoting hooks
      to quote and de-quote filenames.  We were trying to do such quote handling
      within complete_from_files(), and that's still what we have to do if we're
      using libedit, which lacks those hooks.  But for Readline, it works a lot
      better if we tell Readline that single-quote is a quoting character and
      then provide hooks that know the details of the quoting rules for SQL
      and psql meta-commands.
      
      Hence, resurrect the quoting hook functions that existed in the original
      version of tab-complete.c (and were disabled by commit f6689a32 because
      they "didn't work so well yet"), and whack on them until they do seem to
      work well.
      
      Notably, this fixes bug #16059 from Steven Winfield, who pointed out
      that the previous coding would strip quote marks from filenames in SQL
      COPY commands, even though they're syntactically necessary there.
      Now, we not only don't do that, but we'll add a quote mark when you
      tab-complete, even if you didn't type one.
      
      Getting this to work across a range of libedit versions (and, to a
      lesser extent, libreadline versions) was depressingly difficult.
      It will be interesting to see whether the new regression test cases
      pass everywhere in the buildfarm.
      
      Some future patch might try to handle quoted SQL identifiers with
      similar explicit quoting/dequoting logic, but that's for another day.
      
      Patch by me, reviewed by Peter Eisentraut.
      
      Discussion: https://postgr.es/m/16059-8836946734c02b84@postgresql.org
      cd69ec66
    • Michael Paquier's avatar
      Doc: Fix and tweak documentation for ANALYZE reporting · 5ba40b62
      Michael Paquier authored
      The docs had some typos and grammar mistakes, and its indentation was
      inconsistent.
      
      Author: Amit Langote, Justin Pryzby
      Discussion: https://postgr.es/m/20200116151930.GM26045@telsasoft.com
      5ba40b62
    • Michael Paquier's avatar
      Clarify some comments in vacuumlazy.c · f942dfb9
      Michael Paquier authored
      Author: Justin Pryzby
      Discussion: https://postgr.es/m/20200113004542.GA26045@telsasoft.com
      f942dfb9
  8. 22 Jan, 2020 3 commits