From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AS OF queries |
Date: | 2017-12-20 14:03:50 |
Message-ID: | 1513778630.2590.33.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-12-20 14:05:38 | Re: vacuum vs heap_update_tuple() and multixactids |
Previous Message | Joe Wildish | 2017-12-20 14:02:20 | Re: AS OF queries |