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
signature.asc
Description: PGP signature
