Re: automatic restore point

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
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-06-26 01:33:40
Message-ID: CAKFQuwamx96qu6GAM8OuoM3DNEockiiiE=VOx1LV0_Hag5bOrQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 25, 2018 at 6:17 PM, Yotsunaga, Naoki <
yotsunaga(dot)naoki(at)jp(dot)fujitsu(dot)com> wrote:

> ​​
> So what do you think about it? Do you think is it useful?
>

​The cost/benefit ratio seems low...​

Also, when recovering with the current specification, tables other than the
> returned table also return to the state of the specified recovery point.
> So, I’m looking for ways to recover only specific tables. Do you have any
> ideas?
>

...and this lowers it even further.

I'd rather spend effort making the initial execution of said commands less
likely. Something like:

TRUNCATE table YES_I_REALLY_WANT_TO_DO_THIS;

which will fail if you don't add the keyword "YES_I..." to the end of the
command and the system was setup to require it.

Or, less annoyingly:

BEGIN;
SET LOCAL perform_dangerous_action = true; --can we require local?
TRUNCATE table;
COMMIT;

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-06-26 01:41:11 Re: using expression syntax for partition bounds
Previous Message Yotsunaga, Naoki 2018-06-26 01:17:31 automatic restore point