From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "Yotsunaga, Naoki" <yotsunaga(dot)naoki(at)jp(dot)fujitsu(dot)com> |
Cc: | Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: automatic restore point |
Date: | 2018-07-03 01:16:50 |
Message-ID: | 20180703011650.GD2159@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 03, 2018 at 01:07:41AM +0000, Yotsunaga, Naoki wrote:
>> There is also recovery_target_lsn which is new as of v10.
> In this method, it is necessary to look at a lsn position before operating.
> But I assume the user who did not look it before operating.
> So I think that this method is not appropriate.
You should avoid top-posting on the mailing lists, this breaks the
consistency of the thread.
>> So basically what you are looking for here is a way to enforce a
>> restore point to be created depending on a set of pre-defined
>> conditions? How would you define and choose those?
>
> I understand that I was asked how to set up a command to apply this function.
> Ex) DROP = on
> TRUNCATE = off
> Is my interpretation right?
> If my interpretation is correct, all the above commands will be
> applied.
> When this function is turned on, this function works when all the
> above commands are executed.
Yeah, but based on which factors are you able to define that such
conditions are enough to say that this feature is fully-compliant with
user's need, and how can you be sure that this is not going to result in
an additional maintenance burden if you need to define a new set of
conditions in the future. For example an operator has issued a costly
ALTER TABLE which causes a full table rewrite, which could be also an
operation that you would like to prevent. Having a set of GUCs which
define such low-level behavior is not really user-friendly.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-07-03 01:21:59 | Re: automatic restore point |
Previous Message | Robert Haas | 2018-07-03 01:07:58 | Re: pgsql: Clarify use of temporary tables within partition trees |