Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 22 May, 2020 4 commits
  3. 21 May, 2020 5 commits
  5. 20 May, 2020 4 commits
  7. 19 May, 2020 1 commit
    • Peter Geoghegan's avatar
      Reconsider nbtree page deletion assertion. · 67b0b2db
      Peter Geoghegan authored 
      Commit 624686ab added an assertion that verified that _bt_search
successfully relocated the leaf page undergoing deletion.  Page deletion
cannot deal with the case where the descent stack is to the right of the
page, so this seemed critical (deletion can only handle the case where
the descent stack is to the left of the leaf/target page).  However, the
assertion went a bit too far.

Since only a buffer pin is held on the leaf page throughout the call to
_bt_search, nothing guarantees that it can't have split during this
small window.  And if does actually split, _bt_search may end up
"relocating" a page to the right of the original target leaf page.  This
scenario seems extremely unlikely, but it must still be considered.
Remove the assertion, and document how we cope in this scenario.
      67b0b2db
  9. 18 May, 2020 7 commits
  11. 17 May, 2020 6 commits
  13. 16 May, 2020 8 commits
  15. 15 May, 2020 5 commits
    • Tom Lane's avatar
      Drop the redundant "Lock" suffix from LWLock wait event names. · 14a91010
      Tom Lane authored 
      This was mostly confusing, especially since some wait events in
this class had the suffix and some did not.

While at it, stop exposing MainLWLockNames[] as a globally visible
name; any code using that directly is almost certainly wrong, as
its name has been misleading for some time.
(GetLWLockIdentifier() is what to use instead.)

Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
      14a91010
    • Tom Lane's avatar
      Fix bogus initialization of replication origin shared memory state. · 80484049
      Tom Lane authored 
      The previous coding zeroed out offsetof(ReplicationStateCtl, states)
more bytes than it was entitled to, as a consequence of starting the
zeroing from the wrong pointer (or, if you prefer, using the wrong
calculation of how much to zero).

It's unsurprising that this has not caused any reported problems,
since it can be expected that the newly-allocated block is at the end
of what we've used in shared memory, and we always make the shmem
block substantially bigger than minimally necessary.  Nonetheless,
this is wrong and it could bite us someday; plus it's a dangerous
model for somebody to copy.

This dates back to the introduction of this code (commit 5aa23504),
so back-patch to all supported branches.
      80484049
    • Tom Lane's avatar
      Rename assorted LWLock tranches. · 36ac359d
      Tom Lane authored 
      Choose names that fit into the conventions for wait event names
(particularly, that multi-word names are in the style MultiWordName)
and hopefully convey more information to non-hacker users than the
previous names did.

Also rename SerializablePredicateLockListLock to
SerializablePredicateListLock; the old name was long enough to cause
table formatting problems, plus the double occurrence of "Lock" seems
confusing/error-prone.

Also change a couple of particularly opaque LWLock field names.

Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
      36ac359d
    • Alvaro Herrera's avatar
      Add comments linking pg_strftime to timestamptz_to_str · a0ab4f49
      Alvaro Herrera authored
      a0ab4f49
    • Alvaro Herrera's avatar
      Avoid killing btree items that are already dead · 242dfcba
      Alvaro Herrera authored 
      _bt_killitems marks btree items dead when a scan leaves the page where
they live, but it does so with only share lock (to improve concurrency).
This was historicall okay, since killing a dead item has no
consequences.  However, with the advent of data checksums and
wal_log_hints, this action incurs a WAL full-page-image record of the
page.  Multiple concurrent processes would write the same page several
times, leading to WAL bloat.  The probability of this happening can be
reduced by only killing items if they're not already dead, so change the
code to do that.

The problem could eliminated completely by having _bt_killitems upgrade
to exclusive lock upon seeing a killable item, but that would reduce
concurrency so it's considered a cure worse than the disease.

Backpatch all the way back to 9.5, since wal_log_hints was introduced in
9.4.

Author: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Discussion: https://postgr.es/m/CA+fd4k6PeRj2CkzapWNrERkja5G0-6D-YQiKfbukJV+qZGFZ_Q@mail.gmail.com
      242dfcba