Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 05 Jun, 2020 3 commits
    • Tom Lane's avatar
      Use query collation, not column's collation, while examining statistics. · 044c99bc
      Tom Lane authored 
      Commit 5e092800 changed the planner so that, instead of blindly using
DEFAULT_COLLATION_OID when invoking operators for selectivity estimation,
it would use the collation of the column whose statistics we're
considering.  This was recognized as still being not quite the right
thing, but it seemed like a good incremental improvement.  However,
shortly thereafter we introduced nondeterministic collations, and that
creates cases where operators can fail if they're passed the wrong
collation.  We don't want planning to fail in cases where the query itself
would work, so this means that we *must* use the query's collation when
invoking operators for estimation purposes.

The only real problem this creates is in ineq_histogram_selectivity, where
the binary search might produce a garbage answer if we perform comparisons
using a different collation than the column's histogram is ordered with.
However, when the query's collation is significantly different from the
column's default collation, the estimate we previously generated would be
pretty irrelevant anyway; so it's not clear that this will result in
noticeably worse estimates in practice.  (A follow-on patch will improve
this situation in HEAD, but it seems too invasive for back-patch.)

The patch requires changing the signatures of mcv_selectivity and allied
functions, which are exported and very possibly are used by extensions.
In HEAD, I just did that, but an API/ABI break of this sort isn't
acceptable in stable branches.  Therefore, in v12 the patch introduces
"mcv_selectivity_ext" and so on, with signatures matching HEAD, and makes
the old functions into wrappers that assume DEFAULT_COLLATION_OID should
be used.  That does not match the prior behavior, but it should avoid risk
of failure in most cases.  (In practice, I think most extension datatypes
aren't collation-aware, so the change probably doesn't matter to them.)

Per report from James Lucas.  Back-patch to v12 where the problem was
introduced.

Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com
      044c99bc
    • Peter Eisentraut's avatar
      OpenSSL 3.0.0 compatibility in tests · f0d2c65f
      Peter Eisentraut authored 
      DES has been deprecated in OpenSSL 3.0.0 which makes loading keys
encrypted with DES fail with "fetch failed".  Solve by changing the
cipher used to aes256 which has been supported since 1.0.1 (and is
more realistic to use anyways).

Note that the minimum supported OpenSSL version is 1.0.1 as of
7b283d0e, so this does not introduce
any new version requirements.

Author: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://www.postgresql.org/message-id/flat/FEF81714-D479-4512-839B-C769D2605F8A%40yesql.se
      f0d2c65f
    • Michael Paquier's avatar
      Preserve pg_index.indisreplident across REINDEX CONCURRENTLY · 1127f0e3
      Michael Paquier authored 
      If the flag value is lost, logical decoding would work the same way as
REPLICA IDENTITY NOTHING, meaning that no old tuple values would be
included in the changes anymore produced by logical decoding.

Author: Michael Paquier
Reviewed-by: Euler Taveira
Discussion: https://postgr.es/m/20200603065340.GK89559@paquier.xyz
Backpatch-through: 12
      1127f0e3
  3. 04 Jun, 2020 4 commits
    • Tom Lane's avatar
      Reject "23:59:60.nnn" in datetime input. · a9632830
      Tom Lane authored 
      It's intentional that we don't allow values greater than 24 hours,
while we do allow "24:00:00" as well as "23:59:60" as inputs.
However, the range check was miscoded in such a way that it would
accept "23:59:60.nnn" with a nonzero fraction.  For time or timetz,
the stored result would then be greater than "24:00:00" which would
fail dump/reload, not to mention possibly confusing other operations.

Fix by explicitly calculating the result and making sure it does not
exceed 24 hours.  (This calculation is redundant with what will happen
later in tm2time or tm2timetz.  Maybe someday somebody will find that
annoying enough to justify refactoring to avoid the duplication; but
that seems too invasive for a back-patched bug fix, and the cost is
probably unmeasurable anyway.)

Note that this change also rejects such input as the time portion
of a timestamp(tz) value.

Back-patch to v10.  The bug is far older, but to change this pre-v10
we'd need to ensure that the logic behaves sanely with float timestamps,
which is possibly nontrivial due to roundoff considerations.
Doesn't really seem worth troubling with.

Per report from Christoph Berg.

Discussion: https://postgr.es/m/20200520125807.GB296739@msg.df7cb.de
      a9632830
    • Peter Eisentraut's avatar
      psql: Clean up terminology in \dAp command · f5067049
      Peter Eisentraut authored 
      The preferred terminology has been support "function", not procedure,
for some time, so change that over.  The command stays \dAp, since
\dAf is already something else.
      f5067049
    • Michael Paquier's avatar
      Fix comment in be-secure-openssl.c · 3fa44a30
      Michael Paquier authored 
      Since 573bd08b, hardcoded DH parameters have been moved to a different
file, making the comment on top of load_dh_buffer() incorrect.

Author: Daniel Gustafsson
Discussion: https://postgr.es/m/D9492CCB-9A91-4181-A847-1779630BE2A7@yesql.se
      3fa44a30
    • Michael Paquier's avatar
      Fix instance of elog() called while holding a spinlock · c1669fd5
      Michael Paquier authored 
      This broke the project rule to not call any complex code while a
spinlock is held.  Issue introduced by b89e1510.

Discussion: https://postgr.es/m/20200602.161518.1399689010416646074.horikyota.ntt@gmail.com
Backpatch-through: 9.5
      c1669fd5
  5. 03 Jun, 2020 3 commits
    • Tom Lane's avatar
      Don't call palloc() while holding a spinlock, either. · f88bd313
      Tom Lane authored 
      Fix some more violations of the "only straight-line code inside a
spinlock" rule.  These are hazardous not only because they risk
holding the lock for an excessively long time, but because it's
possible for palloc to throw elog(ERROR), leaving a stuck spinlock
behind.

copy_replication_slot() had two separate places that did pallocs
while holding a spinlock.  We can make the code simpler and safer
by copying the whole ReplicationSlot struct into a local variable
while holding the spinlock, and then referencing that copy.
(While that's arguably more cycles than we really need to spend
holding the lock, the struct isn't all that big, and this way seems
far more maintainable than copying fields piecemeal.  Anyway this
is surely much cheaper than a palloc.)  That bug goes back to v12.

InvalidateObsoleteReplicationSlots() not only did a palloc while
holding a spinlock, but for extra sloppiness then leaked the memory
--- probably for the lifetime of the checkpointer process, though
I didn't try to verify that.  Fortunately that silliness is new
in HEAD.

pg_get_replication_slots() had a cosmetic violation of the rule,
in that it only assumed it's safe to call namecpy() while holding
a spinlock.  Still, that's a hazard waiting to bite somebody, and
there were some other cosmetic coding-rule violations in the same
function, so clean it up.  I back-patched this as far as v10; the
code exists before that but it looks different, and this didn't
seem important enough to adapt the patch further back.

Discussion: https://postgr.es/m/20200602.161518.1399689010416646074.horikyota.ntt@gmail.com
      f88bd313
    • Bruce Momjian's avatar
      doc: PG 13 relnotes: fix link for grouping sets hash overflow · 4d685f6d
      Bruce Momjian authored 
      Use "guc-enable-groupingsets-hash-disk".

Reported-by: TAKATSUKA Haruka

Discussion: https://postgr.es/m/16468-7939d39f1786516c@postgresql.org

Backpatch-through: master
      4d685f6d
    • Fujii Masao's avatar
      doc: Move wal_init_zero and wal_recycle descriptions to proper section. · 43e592c7
      Fujii Masao authored 
      The group of wal_init_zero and wal_recycle is WAL_SETTINGS in guc.c,
but previously their documents were located in
"Replication"/"Sending Servers" section. This commit moves them to
the proper section "Write Ahead Log"/"Settings".

Back-patch to v12 where wal_init_zero and wal_recycle parameters
were introduced.

Author: Fujii Masao
Discussion: https://postgr.es/m/b5190ab4-a169-6a42-0e49-aed0807c8976@oss.nttdata.com
      43e592c7
  7. 02 Jun, 2020 2 commits
  9. 01 Jun, 2020 4 commits
  11. 31 May, 2020 3 commits
  13. 29 May, 2020 1 commit
  15. 28 May, 2020 7 commits
  17. 27 May, 2020 1 commit
  19. 26 May, 2020 5 commits
  21. 25 May, 2020 3 commits
  23. 23 May, 2020 1 commit
  25. 22 May, 2020 3 commits