On Wed, Dec 20, 2017 at 03:03:50PM +0100, Laurenz Albe wrote:
> Konstantin Knizhnik wrote:
> > Please notice that it is necessary to configure postgres in proper
> > way in order to be able to perform time travels. If you do not
> > disable autovacuum, then old versions will be just cleaned-up. If
> > transaction commit timestamps are not tracked, then it is not
> > possible to locate required timeline.
> >
> > So DBA should make a decision in advance whether this feature is
> > needed or not. It is not a proper instrument for
> > restoring/auditing existed database which was not configured to
> > keep all versions.
>
> Of course; you'd have to anticipate the need to travel in time, and
> you have to pay the price for it. Anybody who has read science
> fiction stories know that time travel does not come free.
A few extra terabytes' worth of storage space is a pretty small price
to pay, at least on the scale of time travel penalties.
> > May be it is better to add special configuration parameter for
> > this feature which should implicitly toggle autovacuum and
> > track_commit_timestamp parameters).
>
> The feature would be most useful with some kind of "moving xid
> horizon" that guarantees that only dead tuples whose xmax lies more
> than a certain time interval in the past can be vacuumed.
+1 for this horizon. It would be very nice, but maybe not strictly
necessary, for this to be adjustable downward without a restart.
It's not clear that adjusting it upward should work at all, but if it
did, the state of dead tuples would have to be known, and they'd have
to be vacuumed a way that was able to establish a guarantee of
gaplessness at least back to the new horizon. Maybe there could be
some kind of "high water mark" for it. Would that impose overhead or
design constraints on vacuum that we don't want?
Also nice but not strictly necessary, making it tunable per relation,
or at least per table. I'm up in the air as to whether queries with
an AS OF older than the horizon[1] should error out or merely throw
warnings.
Best,
David.
[1] If we allow setting this at granularities coarser than DB
instance, this means going as far back as the relationship with the
newest "last" tuple among the relations involved in the query.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
