Re: fixing old_snapshot_threshold's time->xid mapping - Mailing list pgsql-hackers

From Andres Freund
Subject Re: fixing old_snapshot_threshold's time->xid mapping
Date
Msg-id 20200416174601.qpicxtpwblq5elmy@alap3.anarazel.de
Whole thread Raw
In response to Re: fixing old_snapshot_threshold's time->xid mapping  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: fixing old_snapshot_threshold's time->xid mapping  (Thomas Munro <thomas.munro@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: fixing old_snapshot_threshold's time->xid mapping
Next
From: Thomas Munro
Date:
Subject: Re: Should we add xid_current() or a int8->xid cast?