Re: automatic restore point

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: automatic restore point
Дата
Msg-id 20180711063336.GB14301@paquier.xyz
обсуждение исходный текст
Ответ на RE: automatic restore point  ("Yotsunaga, Naoki" <yotsunaga.naoki@jp.fujitsu.com>)
Ответы RE: automatic restore point  ("Yotsunaga, Naoki" <yotsunaga.naoki@jp.fujitsu.com>)
Список pgsql-hackers
On Wed, Jul 11, 2018 at 06:11:01AM +0000, Yotsunaga, Naoki wrote:
> I want to hear about the following in addition to the previous
> comment.   What would you do if your customer dropped the table and asked you to
> restore it?

I can think of 4 reasons on top of my mind:
1) Don't do that.
2) Implement safe-guards using utility hooks or event triggers.
3) Have a delayed standby if you don't believe that your administrators
are skilled enough in case.
4) Have backups and a WAL archive.

> Everyone is thinking what to do to avoid operation failure, but I’m
> thinking about after the user’s failure.
> What I mean is that not all users will set up in advance.
> For example, if you make the settings described in the manual, you
> will not drop the table by operation failure. However, not all users
> do that setting.
> For such users, I think that it is necessary to have a function to
> easily restore data after failing operation without setting anything
> in advance. So I proposed this function.

Well, if you put in place correct measures from the start you would not
have problems.  It seems to me that there is no point in implementing
something which is a solution for a very narrow case, where the user has
shot his own foot to begin with.  Having backups anyway is mandatory by
the way, standby replicas are not backups.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Problem with tupdesc in jsonb_to_recordset
Следующее
От: Kuntal Ghosh
Дата:
Сообщение: In pageinspect, perform clean-up after testing gin-related functions