Fix two bugs in MaintainOldSnapshotTimeMapping.
authorRobert Haas <rhaas@postgresql.org>
Thu, 24 Sep 2020 19:27:19 +0000 (15:27 -0400)
committerRobert Haas <rhaas@postgresql.org>
Thu, 24 Sep 2020 19:27:19 +0000 (15:27 -0400)
commit55b7e2f4d78d8aa7b4a5eae9a0a810601d03c563
tree5cc04c2de7b7475f5c7f1b8491742bbe103438dd
parentc005eb00e7d878cb869854f592103f774e15d01e
Fix two bugs in MaintainOldSnapshotTimeMapping.

The previous coding was confused about whether head_timestamp was
intended to represent the timestamp for the newest bucket in the
mapping or the oldest timestamp for the oldest bucket in the mapping.
Decide that it's intended to be the oldest one, and repair
accordingly.

To do that, we need to do two things. First, when advancing to a
new bucket, don't categorically set head_timestamp to the new
timestamp. Do this only if we're blowing out the map completely
because a lot of time has passed since we last maintained it. If
we're replacing entries one by one, advance head_timestamp by
1 minute for each; if we're filling in unused entries, don't
advance head_timestamp at all.

Second, fix the computation of how many buckets we need to advance.
The previous formula would be correct if head_timestamp were the
timestamp for the new bucket, but we're now making all the code
agree that it's the timestamp for the oldest bucket, so adjust the
formula accordingly.

This is certainly a bug fix, but I don't feel good about
back-patching it without the introspection tools added by commit
aecf5ee2bb36c597d3c6142e367e38d67816c777, and perhaps also some
actual tests. Since back-patching the introspection tools might
not attract sufficient support and since there are no automated
tests of these fixes yet, I'm just committing this to master for
now.

Patch by me, reviewed by Thomas Munro, Dilip Kumar, Hamid Akhtar.

Discussion: http://postgr.es/m/CA+TgmoY=aqf0zjTD+3dUWYkgMiNDegDLFjo+6ze=Wtpik+3XqA@mail.gmail.com
src/backend/utils/time/snapmgr.c