5. mai 2016 6:14 AM kirjutas kuupƤeval "Andres Freund" <and...@anarazel.de>: > > On 2016-05-05 06:08:39 +0300, Ants Aasma wrote: > > On 5 May 2016 1:28 a.m., "Andres Freund" <and...@anarazel.de> wrote: > > > On 2016-05-04 18:22:27 -0400, Robert Haas wrote: > > > > How would the semantics change? > > > > > > Right now the time for computing the snapshot is relevant, if > > > maintenance of xids is moved, it'll likely be tied to the time xids are > > > assigned. That seems perfectly alright, but it'll change behaviour. > > > > FWIW moving the maintenance to a clock tick process will not change user > > visible semantics in any significant way. The change could easily be made > > in the next release. > > I'm not convinced of that - right now the timeout is computed as a > offset to the time a snapshot with a certain xmin horizon is > taken. Moving the computation to GetNewTransactionId() or a clock tick > process will make it relative to the time an xid has been generated > (minus a fuzz factor). That'll behave differently in a number of cases, no?
Timeout is calculated in TransactionIdLimitedForOldSnapshots() as GetSnapshotCurrentTimestamp() minus old_snapshot_timeout rounded down to previous minute. If the highest seen xmin in that minute is useful in raising cleanup xmin the threshold is bumped. Snapshots switch behavior when their whenTaken is past this threshold. Xid generation time has no effect on this timing, it's completely based on passage of time. The needed invariant is, that no snapshot having whenTaken after timeout timestamp can have xmin less than calculated bound. Moving the xmin calculation and storage to clock tick actually makes the bound tighter. The ordering between xmin calculation and clok update/read needs to be correct to ensure the invariant. Regards, Ants Aasma