Re: automatic restore point

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: automatic restore point
Дата
Msg-id CAKFQuwamx96qu6GAM8OuoM3DNEockiiiE=VOx1LV0_Hag5bOrQ@mail.gmail.com
обсуждение исходный текст
Ответ на automatic restore point  ("Yotsunaga, Naoki" <yotsunaga.naoki@jp.fujitsu.com>)
Ответы Re: automatic restore point  (Isaac Morland <isaac.morland@gmail.com>)
Список pgsql-hackers
On Mon, Jun 25, 2018 at 6:17 PM, Yotsunaga, Naoki <yotsunaga.naoki@jp.fujitsu.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Yotsunaga, Naoki"
Дата:
Сообщение: automatic restore point
Следующее
От: Amit Langote
Дата:
Сообщение: Re: using expression syntax for partition bounds