Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 08 Jul, 2021 3 commits
  3. 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
  7. 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
  9. 04 Jul, 2021 2 commits
  11. 03 Jul, 2021 1 commit
  13. 02 Jul, 2021 4 commits
  15. 01 Jul, 2021 7 commits
  17. 30 Jun, 2021 3 commits
  19. 29 Jun, 2021 5 commits
  21. 28 Jun, 2021 6 commits
    • Tom Lane's avatar
      Don't use abort(3) in libpq's fe-print.c. · cf1f545b
      Tom Lane authored 
      Causing a core dump on out-of-memory seems pretty unfriendly,
and surely is far outside the expected behavior of a general-purpose
library.  Just print an error message (as we did already) and return.
These functions unfortunately don't have an error return convention,
but code using them is probably just looking for a quick-n-dirty
print method and wouldn't bother to check anyway.

Although these functions are semi-deprecated, it still seems
appropriate to back-patch this.  In passing, also back-patch
b90e6cef, just to reduce cosmetic differences between the
branches.

Discussion: https://postgr.es/m/3122443.1624735363@sss.pgh.pa.us
      cf1f545b
    • Tom Lane's avatar
      Don't depend on -fwrapv semantics in pgbench's random() function. · 203c5aaa
      Tom Lane authored 
      Instead use the common/int.h functions to check for integer overflow
in a more C-standard-compliant fashion.  This is motivated by recent
failures on buildfarm member moonjelly, where it appears that
development-tip gcc is optimizing without regard to the -fwrapv
switch.  Presumably that's a gcc bug that will be fixed soon, but
we might as well install cleaner coding here rather than wait.

(This does not address the question of whether we'll ever be able
to get rid of using -fwrapv.  Testing shows that this spot is the
only place where doing so creates visible regression test failures,
but unfortunately that proves very little.)

Back-patch to v12.  The common/int.h functions exist in v11, but
that branch doesn't use them in any client-side code.  I judge
that this case isn't interesting enough in the real world to take
even a small risk of issues from being the first such use.

Tom Lane and Fabien Coelho

Discussion: https://postgr.es/m/73927.1624815543@sss.pgh.pa.us
      203c5aaa
    • Andrew Dunstan's avatar
      Pre branch pgindent / pgperltidy run · e1c1c30f
      Andrew Dunstan authored 
      Along the way make a slight adjustment to
src/include/utils/queryjumble.h to avoid an unused typedef.
      e1c1c30f
    • Peter Eisentraut's avatar
      Message style improvements · c3183377
      Peter Eisentraut authored
      c3183377
    • Amit Kapila's avatar
      Improve RelationGetIdentityKeyBitmap(). · ee3fdb8f
      Amit Kapila authored 
      We were using RelationGetIndexList() to update the relation's replica
identity index but instead, we can directly use RelationGetReplicaIndex()
which uses the same functionality. This is a minor code readability
improvement.

Author: Japin Li
Reviewed-By: Takamichi Osumi, Amit Kapila
Discussion: https://postgr.es/m/4C99A862-69C8-431F-960A-81B1151F1B89@enterprisedb.com
      ee3fdb8f
    • Amit Kapila's avatar
      Fix race condition in TransactionGroupUpdateXidStatus(). · b786304c
      Amit Kapila authored 
      When we cannot immediately acquire XactSLRULock in exclusive mode at
commit time, we add ourselves to a list of processes that need their XIDs
status update. We do this if the clog page where we need to update the
current transaction status is the same as the group leader's clog page,
otherwise, we allow the caller to clear it by itself. Now, when we can't
add ourselves to any group, we were not clearing the current proc if it
has already become a member of some group which was leading to an
assertion failure when the same proc was assigned to another backend after
the current backend exits.

Reported-by: Alexander Lakhin
Bug: 17072
Author: Amit Kapila
Tested-By: Alexander Lakhin
Backpatch-through: 11, where it was introduced
Discussion: https://postgr.es/m/17072-2f8764857ef2c92a@postgresql.org
      b786304c