RE: automatic restore point

Поиск
Список
Период
Сортировка
От Yotsunaga, Naoki
Тема RE: automatic restore point
Дата
Msg-id 8E9126CB6CE2CD42962059AB0FBF7B0DBF6C89@g01jpexmbkw23
обсуждение исходный текст
Ответ на RE: automatic restore point  ("Yotsunaga, Naoki" <yotsunaga.naoki@jp.fujitsu.com>)
Ответы Re: automatic restore point  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
>-----Original Message-----
>From: Yotsunaga, Naoki [mailto:yotsunaga.naoki@jp.fujitsu.com] 
>Sent: Friday, July 6, 2018 5:05 PM

>Does that mean that the application (user) is interested in which table? 
>For example, there are two tables A. It is ok even if one table disappears, but it is troubled if another table B
disappears.So, when the table B is dropped, automatic restore point works. In the table A, automatic restore point does
notwork. 
 
>So, it is difficult to implement that automatic restore point in postgresql by default. 
>Is my interpretation right?

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?
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
settinganything in advance.
 
So I proposed this function.

---
Naoki Yotsunaga






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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Restricting maximum keep segments by repslots
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Problem with tupdesc in jsonb_to_recordset