1. 15 Jan, 2019 1 commit
    • Andres Freund's avatar
      Don't include heapam.h from others headers. · 4c850ece
      Andres Freund authored
      heapam.h previously was included in a number of widely used
      headers (e.g. execnodes.h, indirectly in executor.h, ...). That's
      problematic on its own, as heapam.h contains a lot of low-level
      details that don't need to be exposed that widely, but becomes more
      problematic with the upcoming introduction of pluggable table storage
      - it seems inappropriate for heapam.h to be included that widely
      afterwards.
      
      heapam.h was largely only included in other headers to get the
      HeapScanDesc typedef (which was defined in heapam.h, even though
      HeapScanDescData is defined in relscan.h). The better solution here
      seems to be to just use the underlying struct (forward declared where
      necessary). Similar for BulkInsertState.
      
      Another problem was that LockTupleMode was used in executor.h - parts
      of the file tried to cope without heapam.h, but due to the fact that
      it indirectly included it, several subsequent violations of that goal
      were not not noticed. We could just reuse the approach of declaring
      parameters as int, but it seems nicer to move LockTupleMode to
      lockoptions.h - that's not a perfect location, but also doesn't seem
      bad.
      
      As a number of files relied on implicitly included heapam.h, a
      significant number of files grew an explicit include. It's quite
      probably that a few external projects will need to do the same.
      
      Author: Andres Freund
      Reviewed-By: Alvaro Herrera
      Discussion: https://postgr.es/m/20190114000701.y4ttcb74jpskkcfb@alap3.anarazel.de
      4c850ece
  2. 14 Jan, 2019 4 commits
    • Michael Paquier's avatar
      Fix typos in documentation and for one wait event · 42e2a580
      Michael Paquier authored
      These have been found while cross-checking for the use of unique words
      in the documentation, and a wait event was not getting generated in a way
      consistent to what the documentation provided.
      
      Author: Alexander Lakhin
      Discussion: https://postgr.es/m/9b5a3a85-899a-ae62-dbab-1e7943aa5ab1@gmail.com
      42e2a580
    • Andres Freund's avatar
      Re-add default_with_oids GUC to avoid breaking old dump files. · de66987a
      Andres Freund authored
      After 578b2297 / the removal of WITH OIDS support, older dump files
      containing
          SET default_with_oids = false;
      either report unnecessary errors (as the subsequent tables have no
      oids) or even fail to restore entirely (when using transaction mode).
      To avoid that, re-add the GUC, but don't allow setting it to true.
      
      Per complaint from Tom Lane.
      
      Author: Amit Khandekar, editorialized by me
      Discussion: https://postgr.es/m/CAJ3gD9dZyxrtL0rJfoNoOj6v7fJSDaXBngi9wy5XU8m-ioXhAA@mail.gmail.com
      de66987a
    • Alvaro Herrera's avatar
      Fix unique INCLUDE indexes on partitioned tables · 0ad41cf5
      Alvaro Herrera authored
      We were considering the INCLUDE columns as part of the key, allowing
      unicity-violating rows to be inserted in different partitions.
      
      Concurrent development conflict in eb7ed3f3 and 8224de4f.
      
      Reported-by: Justin Pryzby
      Discussion: https://postgr.es/m/20190109065109.GA4285@telsasoft.com
      0ad41cf5
    • Heikki Linnakangas's avatar
      Detach postmaster process from pg_ctl's session at server startup. · bb24439c
      Heikki Linnakangas authored
      pg_ctl is supposed to daemonize the postmaster process, so that it's not
      affected by signals to the launching process group.  Before this patch, if
      you had a shell script that used "pg_ctl start", and you interrupted the
      shell script after postmaster had been launched, postmaster was also
      killed.  To fix, call setsid() after forking the postmaster process.
      
      Long time ago, we had a 'silent_mode' option, which daemonized the
      postmaster process by calling setsid(), but that was removed back in 2011
      (commit f7ea6bea).  We discussed bringing that back in some form, but
      pg_ctl is the documented way of launching postmaster to the background, so
      putting the setsid() call in pg_ctl itself seems appropriate.
      
      Just putting postmaster in a separate session would change the behavior
      when you interrupt "pg_ctl -w start", e.g. with CTRL-C, while it's waiting
      for postmaster to start.  The historical behavior has been that
      interrupting pg_ctl aborts the server launch, which is handy if the server
      is stuck in recovery, for example, and won't fully start up.  To keep that
      behavior, install a signal handler in pg_ctl, to explicitly kill
      postmaster, if pg_ctl is interrupted while it's waiting for the server to
      start up.  This isn't 100% watertight, there is a small window after
      forking the postmaster process, where the signal handler doesn't know the
      postmaster's PID yet, but seems good enough.
      
      Arguably this is a long-standing bug, but I refrained from back-batching,
      out of fear of breaking someone's scripts that depended on the old
      behavior.
      
      Reviewed by Tom Lane.  Report and original patch by Paul Guo, with
      feedback from Michael Paquier.
      
      Discussion: https://www.postgresql.org/message-id/CAEET0ZH5Bf7dhZB3mYy8zZQttJrdZg_0Wwaj0o1PuuBny1JkEw%40mail.gmail.com
      bb24439c
  3. 13 Jan, 2019 10 commits
  4. 11 Jan, 2019 6 commits
    • Andrew Dunstan's avatar
      Free pre-modification HeapTuple in ALTER TABLE ... TYPE ... · e33884d4
      Andrew Dunstan authored
      This was an oversight in commit 3b174b1a.
      
      Per offline gripe from Alvaro Herrera
      
      Backpatch to release 11.
      e33884d4
    • Tom Lane's avatar
      Avoid sharing PARAM_EXEC slots between different levels of NestLoop. · 1db5667b
      Tom Lane authored
      Up to now, createplan.c attempted to share PARAM_EXEC slots for
      NestLoopParams across different plan levels, if the same underlying Var
      was being fed down to different righthand-side subplan trees by different
      NestLoops.  This was, I think, more of an artifact of using subselect.c's
      PlannerParamItem infrastructure than an explicit design goal, but anyway
      that was the end result.
      
      This works well enough as long as the plan tree is executing synchronously,
      but the feature whereby Gather can execute the parallelized subplan locally
      breaks it.  An upper NestLoop node might execute for a row retrieved from
      a parallel worker, and assign a value for a PARAM_EXEC slot from that row,
      while the leader's copy of the parallelized subplan is suspended with a
      different active value of the row the Var comes from.  When control
      eventually returns to the leader's subplan, it gets the wrong answers if
      the same PARAM_EXEC slot is being used within the subplan, as reported
      in bug #15577 from Bartosz Polnik.
      
      This is pretty reminiscent of the problem fixed in commit 46c508fb, and
      the proper fix seems to be the same: don't try to share PARAM_EXEC slots
      across different levels of controlling NestLoop nodes.
      
      This requires decoupling NestLoopParam handling from PlannerParamItem
      handling, although the logic remains somewhat similar.  To avoid bizarre
      division of labor between subselect.c and createplan.c, I decided to move
      all the param-slot-assignment logic for both cases out of those files
      and put it into a new file paramassign.c.  Hopefully it's a bit better
      documented now, too.
      
      A regression test case for this might be nice, but we don't know a
      test case that triggers the problem with a suitably small amount
      of data.
      
      Back-patch to 9.6 where we added Gather nodes.  It's conceivable that
      related problems exist in older branches; but without some evidence
      for that, I'll leave the older branches alone.
      
      Discussion: https://postgr.es/m/15577-ca61ab18904af852@postgresql.org
      1db5667b
    • Peter Eisentraut's avatar
      doc: Correct documentation of install-time environment variables · 8b89a886
      Peter Eisentraut authored
      Since approximately PostgreSQL 10, it is no longer required that
      environment variables at installation time such as PERL, PYTHON, TCLSH
      be "full path names", so change that phrasing in the installation
      instructions.  (The exact time of change appears to differ for PERL
      and the others, but it works consistently in PostgreSQL 10.)
      
      Also while we're here document the defaults for PERL and PYTHON, but
      since the search list for TCLSH is so long, let's leave that out so we
      don't need to maintain a copy of that list in the installation
      instructions.
      8b89a886
    • Peter Eisentraut's avatar
      Create INSTALL file using Pandoc · 96b8b8b6
      Peter Eisentraut authored
      Replace using lynx with using pandoc.  Pandoc creates better looking
      output and it avoids the delicate locale/encoding issues of lynx because
      it always uses UTF-8 for both input and output.
      
      Note: requires Pandoc >=1.13
      
      Discussion: https://www.postgresql.org/message-id/flat/dcfaa74d-8037-bb32-f9e0-3fea7ccf4551@2ndquadrant.com/Reviewed-by: default avatarMi Tar <mmitar@gmail.com>
      96b8b8b6
    • Peter Eisentraut's avatar
      Add value 'current' for recovery_target_timeline · ff853060
      Peter Eisentraut authored
      This value represents the default behavior of using the current
      timeline.  Previously, this was represented by an empty string.
      
      (Before the removal of recovery.conf, this setting could not be chosen
      explicitly but was used when recovery_target_timeline was not
      mentioned at all.)
      
      Discussion: https://www.postgresql.org/message-id/flat/6dd2c23a-4162-8469-410f-bfe146e28c0c@2ndquadrant.com/Reviewed-by: default avatarDavid Steele <david@pgmasters.net>
      Reviewed-by: default avatarMichael Paquier <michael@paquier.xyz>
      ff853060
    • Amit Kapila's avatar
      Extend pg_stat_statements_reset to reset statistics specific to a · 43cbedab
      Amit Kapila authored
      particular user/db/query.
      
      The function pg_stat_statements_reset() is extended to accept userid, dbid,
      and queryid as input parameters.  Now, it can discard the statistics
      gathered so far by pg_stat_statements corresponding to the specified
      userid, dbid, and queryid.  If no parameter is specified or all the
      specified parameters have default value aka 0, it will discard all
      statistics as per the old behavior.
      
      The new behavior is useful to get the fresh statistics for a specific
      user/database/query without resetting all the existing statistics.
      
      Author: Haribabu Kommi, with few additional changes by me
      Reviewed-by: Michael Paquier, Amit Kapila and Fujii Masao
      Discussion: https://postgr.es/m/CAJrrPGcyh-gkFswyc6C661K6cknL0XkNqVT0sQt2mFNMR4HRKA@mail.gmail.com
      43cbedab
  5. 10 Jan, 2019 10 commits
  6. 09 Jan, 2019 2 commits
    • Tom Lane's avatar
      Reduce the size of the fmgr_builtin_oid_index[] array. · 8ff5f824
      Tom Lane authored
      This index array was originally defined to have 10000 entries (ranging
      up to FirstGenbkiObjectId), but we really only need entries up to the
      last existing builtin function OID, currently 6121.  That saves close
      to 8K of never-accessed space in the server executable, at the small
      price of one more fetch in fmgr_isbuiltin().
      
      We could reduce the array size still further by renumbering a few of
      the highest-numbered builtin functions; but there's a small risk of
      breaking clients that have chosen to hardwire those function OIDs,
      so it's not clear if it'd be worth the trouble.  (We should, however,
      discourage future patches from choosing function OIDs above 6K as long
      as there's still lots of space below that.)
      
      Discussion: https://postgr.es/m/12359.1547063064@sss.pgh.pa.us
      8ff5f824
    • Tom Lane's avatar
      Update docs & tests to reflect that unassigned OLD/NEW are now NULL. · 59029b6f
      Tom Lane authored
      For a long time, plpgsql has allowed trigger functions to parse
      references to OLD and NEW even if the current trigger event type didn't
      assign a value to one or the other variable; but actually executing such
      a reference would fail.  The v11 changes to use "expanded records" for
      DTYPE_REC variables changed the behavior so that the unassigned variable
      now reads as a null composite value.  While this behavioral change was
      more or less unintentional, it seems that leaving it like this is better
      than adding code and complexity to be bug-compatible with the old way.
      The change doesn't break any code that worked before, and it eliminates
      a gotcha that often required extra code to work around.
      
      Hence, update the docs to say that these variables are "null" not
      "unassigned" when not relevant to the event type.  And add a regression
      test covering the behavior, so that we'll notice if we ever break it
      again.
      
      Per report from Kristjan Tammekivi.
      
      Discussion: https://postgr.es/m/CAABK7uL-uC9ZxKBXzo_68pKt7cECfNRv+c35CXZpjq6jCAzYYA@mail.gmail.com
      59029b6f
  7. 08 Jan, 2019 3 commits
  8. 07 Jan, 2019 4 commits