1. 10 Jul, 2021 2 commits
  2. 09 Jul, 2021 8 commits
    • Tom Lane's avatar
      Un-break AIX build, take 2. · 9ffad7ae
      Tom Lane authored
      I incorrectly diagnosed the reason why hoverfly is unhappy.
      Looking closer, it appears that it fails to link libldap
      unless libssl is also present; so the problem was my
      idea of clearing LIBS before making the check.  Revert
      to essentially the original coding, except that instead
      of failing when libldap_r isn't there, use libldap.
      
      Per buildfarm member hoverfly.
      
      Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org
      9ffad7ae
    • Alvaro Herrera's avatar
      libpq: Fix sending queries in pipeline aborted state · 1beaa654
      Alvaro Herrera authored
      When sending queries in pipeline mode, we were careless about leaving
      the connection in the right state so that PQgetResult would behave
      correctly; trying to read further results after sending a query after
      having read a result with an error would sometimes hang.  Fix by
      ensuring internal libpq state is changed properly.  All the state
      changes were being done by the callers of pqAppendCmdQueueEntry(); it
      would have become too repetitious to have this logic in each of them, so
      instead put it all in that function and relieve callers of the
      responsibility.
      
      Add a test to verify this case.  Without the code fix, this new test
      hangs sometimes.
      
      Also, document that PQisBusy() would return false when no queries are
      pending result.  This is not intuitively obvious, and NULL would be
      obtained by calling PQgetResult() at that point, which is confusing.
      Wording by Boris Kolpackov.
      
      In passing, fix bogus use of "false" to mean "0", per Ranier Vilela.
      
      Backpatch to 14.
      
      Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
      Reported-by: default avatarBoris Kolpackov <boris@codesynthesis.com>
      Discussion: https://postgr.es/m/boris.20210624103805@codesynthesis.com
      1beaa654
    • Tom Lane's avatar
      Un-break AIX build. · 7f2eca6f
      Tom Lane authored
      In commit d0a02bdb8, I'd supposed that uniformly probing for
      ldap_bind would make the intent clearer.  However, that seems
      not to work on AIX, for obscure reasons (maybe it's a macro
      there?).  Revert to the former behavior of probing
      ldap_simple_bind for thread-safe cases and ldap_bind otherwise.
      
      Per buildfarm member hoverfly.
      
      Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org
      7f2eca6f
    • Tom Lane's avatar
      Avoid creating a RESULT RTE that's marked LATERAL. · 1d98fdae
      Tom Lane authored
      Commit 7266d099 added code to pull up simple constant function
      results, converting the RTE_FUNCTION RTE to a dummy RTE_RESULT
      RTE since it no longer need be scanned.  But I forgot to clear
      the LATERAL flag if the RTE has it set.  If the function reduced
      to a constant, it surely contains no lateral references so this
      simplification is logically OK.  It's needed because various other
      places will Assert that RESULT RTEs aren't LATERAL.
      
      Per bug #17097 from Yaoguang Chen.  Back-patch to v13 where the
      faulty code came in.
      
      Discussion: https://postgr.es/m/17097-3372ef9f798fc94f@postgresql.org
      1d98fdae
    • Tom Lane's avatar
      Update configure's probe for libldap to work with OpenLDAP 2.5. · 5620ec83
      Tom Lane authored
      The separate libldap_r is gone and libldap itself is now always
      thread-safe.  Unfortunately there seems no easy way to tell by
      inspection whether libldap is thread-safe, so we have to take
      it on faith that libldap is thread-safe if there's no libldap_r.
      That should be okay, as it appears that libldap_r was a standard
      part of the installation going back at least 20 years.
      
      Report and patch by Adrian Ho.  Back-patch to all supported
      branches, since people might try to build any of them with
      a newer OpenLDAP.
      
      Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org
      5620ec83
    • Tom Lane's avatar
      Reject cases where a query in WITH rewrites to just NOTIFY. · 39b6e85f
      Tom Lane authored
      Since the executor can't cope with a utility statement appearing
      as a node of a plan tree, we can't support cases where a rewrite
      rule inserts a NOTIFY into an INSERT/UPDATE/DELETE command appearing
      in a WITH clause of a larger query.  (One can imagine ways around
      that, but it'd be a new feature not a bug fix, and so far there's
      been no demand for it.)  RewriteQuery checked for this, but it
      missed the case where the DML command rewrites to *only* a NOTIFY.
      That'd lead to crashes later on in planning.  Add the missed check,
      and improve the level of testing of this area.
      
      Per bug #17094 from Yaoguang Chen.  It's been busted since WITH
      was introduced, so back-patch to all supported branches.
      
      Discussion: https://postgr.es/m/17094-bf15dff55eaf2e28@postgresql.org
      39b6e85f
    • Thomas Munro's avatar
      Remove more obsolete comments about semaphores. · 8d48a343
      Thomas Munro authored
      Commit 6753333f stopped using semaphores as the sleep/wake mechanism for
      heavyweight locks, but some obsolete references to that scheme remained
      in comments.  As with similar commit 25b93a29, back-patch all the way.
      Reviewed-by: default avatarDaniel Gustafsson <daniel@yesql.se>
      Discussion: https://postgr.es/m/CA%2BhUKGLafjB1uzXcy%3D%3D2L3cy7rjHkqOVn7qRYGBjk%3D%3DtMJE7Yg%40mail.gmail.com
      8d48a343
    • David Rowley's avatar
      Fix incorrect return value in pg_size_pretty(bigint) · 6de3a21b
      David Rowley authored
      Due to how pg_size_pretty(bigint) was implemented, it's possible that when
      given a negative number of bytes that the returning value would not match
      the equivalent positive return value when given the equivalent positive
      number of bytes.  This was due to two separate issues.
      
      1. The function used bit shifting to convert the number of bytes into
      larger units.  The rounding performed by bit shifting is not the same as
      dividing.  For example -3 >> 1 = -2, but -3 / 2 = -1.  These two
      operations are only equivalent with positive numbers.
      
      2. The half_rounded() macro rounded towards positive infinity.  This meant
      that negative numbers rounded towards zero and positive numbers rounded
      away from zero.
      
      Here we fix #1 by dividing the values instead of bit shifting.  We fix #2
      by adjusting the half_rounded macro always to round away from zero.
      
      Additionally, adjust the pg_size_pretty(numeric) function to be more
      explicit that it's using division rather than bit shifting.  A casual
      observer might have believed bit shifting was used due to a static
      function being named numeric_shift_right.  However, that function was
      calculating the divisor from the number of bits and performed division.
      Here we make that more clear.  This change is just cosmetic and does not
      affect the return value of the numeric version of the function.
      
      Here we also add a set of regression tests both versions of
      pg_size_pretty() which test the values directly before and after the
      function switches to the next unit.
      
      This bug was introduced in 8a1fab36. Prior to that negative values were
      always displayed in bytes.
      
      Author: Dean Rasheed, David Rowley
      Discussion: https://postgr.es/m/CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com
      Backpatch-through: 9.6, where the bug was introduced.
      6de3a21b
  3. 08 Jul, 2021 3 commits
  4. 07 Jul, 2021 3 commits
    • Tom Lane's avatar
      Fix crash in postgres_fdw for provably-empty remote UPDATE/DELETE. · 30a35bca
      Tom Lane authored
      In 86dc9005, I'd written find_modifytable_subplan with the assumption
      that if the immediate child of a ModifyTable is a Result, it must be
      a projecting Result with a subplan.  However, if the UPDATE or DELETE
      has a provably-constant-false WHERE clause, that's not so: we'll
      generate a dummy subplan with a childless Result.  Add the missing
      null-check so we don't crash on such cases.
      
      Per report from Alexander Pyhalov.
      
      Discussion: https://postgr.es/m/b9a6f53549456b2f3e2fd150dcd79d72@postgrespro.ru
      30a35bca
    • Fujii Masao's avatar
      doc: Fix description about pg_stat_statements.track_planning. · e48f2afe
      Fujii Masao authored
      This commit fixes wrong wording like "a fewer kinds"
      in the description about track_planning option.
      
      Back-patch to v13 where pg_stat_statements.track_planning was added.
      
      Author: Justin Pryzby
      Reviewed-by: Julien Rouhaud, Fujii Masao
      Discussion: https://postgr.es/m/20210418233615.GB7256@telsasoft.com
      e48f2afe
    • Fujii Masao's avatar
      postgres_fdw: Tighten up allowed values for batch_size, fetch_size options. · 4173477b
      Fujii Masao authored
      Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
      treated as valid integers for postgres_fdw options batch_size and fetch_size.
      Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
      for which an error is thrown. This was because endptr was not used
      while converting strings to integers using strtol.
      
      This commit changes the logic so that it uses parse_int function
      instead of strtol as it serves the purpose by returning false in case
      if it is unable to convert the string to integer. Note that
      this function also rounds off the values such as '100.456' to 100 and
      '100.567' or '100.678' to 101.
      
      While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
      
      Since parse_int and parse_real are being used for reloptions and GUCs,
      it is more appropriate to use in postgres_fdw rather than using strtol
      and strtod directly.
      
      Back-patch to v14.
      
      Author: Bharath Rupireddy
      Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
      Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
      4173477b
  5. 06 Jul, 2021 2 commits
  6. 05 Jul, 2021 4 commits
    • Tom Lane's avatar
      Reduce overhead of cache-clobber testing in LookupOpclassInfo(). · 07f1e069
      Tom Lane authored
      Commit 03ffc4d6 added logic to bypass all caching behavior in
      LookupOpclassInfo when CLOBBER_CACHE_ALWAYS is enabled.  It doesn't
      look like I stopped to think much about what that would cost, but
      recent investigation shows that the cost is enormous: it roughly
      doubles the time needed for cache-clobber test runs.
      
      There does seem to be value in this behavior when trying to test
      the opclass-cache loading logic itself, but for other purposes the
      cost is excessive.  Hence, let's back off to doing this only when
      debug_invalidate_system_caches_always is at least 3; or in older
      branches, when CLOBBER_CACHE_RECURSIVELY is defined.
      
      While here, clean up some other minor issues in LookupOpclassInfo.
      Re-order the code so we aren't left with broken cache entries (leading
      to later core dumps) in the unlikely case that we suffer OOM while
      trying to allocate space for a new entry.  (That seems to be my
      oversight in 03ffc4d6.)  Also, in >= v13, stop allocating one array
      entry too many.  That's evidently left over from sloppy reversion in
      851b14b0.
      
      Back-patch to all supported branches, mainly to reduce the runtime
      of cache-clobbering buildfarm animals.
      
      Discussion: https://postgr.es/m/1370856.1625428625@sss.pgh.pa.us
      07f1e069
    • Tom Lane's avatar
      Rethink blocking annotations in detach-partition-concurrently-[34]. · 9fa6fe46
      Tom Lane authored
      In 741d7f10, I tried to make the reports from canceled steps come out
      after the pg_cancel_backend() steps, since that was the most common
      ordering before.  However, that doesn't ensure that a canceled step
      doesn't report even later, as shown in a recent failure on buildfarm
      member idiacanthus.  Rather than complicating things even more with
      additional annotations, let's just force the cancel's effect to be
      reported first.  It's not *that* unnatural-looking.
      
      Back-patch to v14 where these test cases appeared.
      
      Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus&dt=2021-07-02%2001%3A40%3A04
      9fa6fe46
    • Peter Eisentraut's avatar
      doc: Fix quoting markup · 1479c5af
      Peter Eisentraut authored
      1479c5af
    • Amit Kapila's avatar
      Doc: Hash Indexes. · f3690fbd
      Amit Kapila authored
      A new chapter for Hash Indexes, designed to help users understand how
      they work and when to use them.
      
      Backpatch-through 10 where we have made hash indexes durable.
      
      Author: Simon Riggs
      Reviewed-By: Justin Pryzby, Amit Kapila
      Discussion: https://postgr.es/m/CANbhV-HRjNPYgHo--P1ewBrFJ-GpZPb9_25P7=Wgu7s7hy_sLQ@mail.gmail.com
      f3690fbd
  7. 04 Jul, 2021 2 commits
  8. 03 Jul, 2021 1 commit
  9. 02 Jul, 2021 4 commits
  10. 01 Jul, 2021 7 commits
  11. 30 Jun, 2021 3 commits
  12. 29 Jun, 2021 1 commit