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
