Re: what to revert
От | Ants Aasma |
---|---|
Тема | Re: what to revert |
Дата | |
Msg-id | CA+CSw_sTt3ttGbm4NTNJ1fz-HGh6EFKoHEkor3j0wOH-5EzQ3Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: what to revert (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: what to revert
|
Список | pgsql-hackers |
<p dir="ltr">5. mai 2016 6:14 AM kirjutas kuupäeval "Andres Freund" <<a href="mailto:andres@anarazel.de">andres@anarazel.de</a>>:<br/> ><br /> > On 2016-05-05 06:08:39 +0300, Ants Aasmawrote:<br /> > > On 5 May 2016 1:28 a.m., "Andres Freund" <<a href="mailto:andres@anarazel.de">andres@anarazel.de</a>>wrote:<br /> > > > On 2016-05-04 18:22:27 -0400, RobertHaas wrote:<br /> > > > > How would the semantics change?<br /> > > ><br /> > > > Rightnow the time for computing the snapshot is relevant, if<br /> > > > maintenance of xids is moved, it'll likelybe tied to the time xids are<br /> > > > assigned. That seems perfectly alright, but it'll change behaviour.<br/> > ><br /> > > FWIW moving the maintenance to a clock tick process will not change user<br />> > visible semantics in any significant way. The change could easily be made<br /> > > in the next release.<br/> ><br /> > I'm not convinced of that - right now the timeout is computed as a<br /> > offset to thetime a snapshot with a certain xmin horizon is<br /> > taken. Moving the computation to GetNewTransactionId() or aclock tick<br /> > process will make it relative to the time an xid has been generated<br /> > (minus a fuzz factor). That'll behave differently in a number of cases, no?<p dir="ltr">Timeout is calculated in TransactionIdLimitedForOldSnapshots()as GetSnapshotCurrentTimestamp() minus old_snapshot_timeout rounded down to previousminute. If the highest seen xmin in that minute is useful in raising cleanup xmin the threshold is bumped. Snapshotsswitch behavior when their whenTaken is past this threshold. Xid generation time has no effect on this timing, it'scompletely based on passage of time.<p dir="ltr">The needed invariant is, that no snapshot having whenTaken after timeouttimestamp can have xmin less than calculated bound. Moving the xmin calculation and storage to clock tick actuallymakes the bound tighter. The ordering between xmin calculation and clok update/read needs to be correct to ensurethe invariant.<p dir="ltr">Regards,<br /> Ants Aasma <br />
В списке pgsql-hackers по дате отправления: