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

From Thomas Munro
Subject Re: fixing old_snapshot_threshold's time->xid mapping
Date
Msg-id CA+hUKG+HcKg9nW+U1GcZSbFnD8+fYcbYy0MMcq+Gc0rpnSf+zA@mail.gmail.com
Whole thread Raw
In response to Re: fixing old_snapshot_threshold's time->xid mapping  (Andres Freund <andres@anarazel.de>)
Responses Re: fixing old_snapshot_threshold's time->xid mapping  (Thomas Munro <thomas.munro@gmail.com>)
Re: fixing old_snapshot_threshold's time->xid mapping  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, Apr 17, 2020 at 5:46 AM Andres Freund <andres@anarazel.de> wrote:
> 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.

What about a contrib function that lets you clobber
oldSnapshotControl->current_timestamp?  It looks like all times in
this system come ultimately from GetSnapshotCurrentTimestamp(), which
uses that variable to make sure that time never goes backwards.
Perhaps you could abuse that, like so, from test scripts:

postgres=# select * from pg_old_snapshot_time_mapping();
 array_offset |     end_timestamp      | newest_xmin
--------------+------------------------+-------------
            0 | 3000-01-01 13:00:00+13 |         490
(1 row)

postgres=# select pg_clobber_current_snapshot_timestamp('3000-01-01 00:01:00Z');
 pg_clobber_current_snapshot_timestamp
---------------------------------------

(1 row)

postgres=# select * from pg_old_snapshot_time_mapping();
 array_offset |     end_timestamp      | newest_xmin
--------------+------------------------+-------------
            0 | 3000-01-01 13:01:00+13 |         490
            1 | 3000-01-01 13:02:00+13 |         490
(2 rows)

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Making openssl_tls_init_hook OpenSSL specific
Next
From: Robert Haas
Date:
Subject: Re: where should I stick that backup?