Re: fixing old_snapshot_threshold's time->xid mapping
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kevin Grittner <kgrittn@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-04-16T17:46:01Z
Lists: pgsql-hackers
Hi, On 2020-04-16 13:34:39 -0400, Robert Haas wrote: > On Thu, Apr 16, 2020 at 1:14 PM Andres Freund <andres@anarazel.de> wrote: > > I still think we need a way to test this without waiting for hours to > > hit various edge cases. You argued against a fixed binning of > > old_snapshot_threshold/100 arguing its too coarse. How about a 1000 or > > so? For 60 days, the current max for old_snapshot_threshold, that'd be a > > granularity of 01:26:24, which seems fine. The best way I can think of > > that'd keep current GUC values sensible is to change > > old_snapshot_threshold to be float. Ugly, but ...? > > Yeah, 1000 would be a lot better. However, if we switch to a fixed > number of bins, it's going to be a lot more code churn. Given the number of things that need to be addressed around the feature, I am not too concerned about that. > What did you think of my suggestion of making head_timestamp > artificially move backward to simulate the passage of time? I don't think it allows to exercise the various cases well enough. We need to be able to test this feature both interactively as well as in a scripted manner. Edge cases like wrapping around in the time mapping imo can not easily be tested by moving the head timestamp back. Greetings, Andres Freund
Commits
-
Remove the "snapshot too old" feature.
- f691f5b80a85 17.0 landed
-
Fix two bugs in MaintainOldSnapshotTimeMapping.
- 55b7e2f4d78d 14.0 landed
-
Add new 'old_snapshot' contrib module.
- aecf5ee2bb36 14.0 landed
-
Expose oldSnapshotControl definition via new header.
- f5ea92e8d620 14.0 landed