Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 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
  3. 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
  5. 02 Jun, 2020 2 commits
  7. 01 Jun, 2020 4 commits
  9. 31 May, 2020 3 commits
  11. 29 May, 2020 1 commit
  13. 28 May, 2020 7 commits
  15. 27 May, 2020 1 commit
  17. 26 May, 2020 5 commits
  19. 25 May, 2020 3 commits
  21. 23 May, 2020 1 commit
  23. 22 May, 2020 6 commits