Re: automatic restore point

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Yotsunaga, Naoki" <yotsunaga(dot)naoki(at)jp(dot)fujitsu(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: automatic restore point
Date: 2018-07-03 01:21:59
Message-ID: 20180703012159.GE2159@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 03, 2018 at 01:06:31AM +0000, Yotsunaga, Naoki wrote:
>> I'd rather spend effort making the initial execution of said commands
>> less likely.
>
> I think that the function to prohibit DELETE and UPDATE without a
> WHERE clause in the later response is good way.

This has popped up already in the lists in the past.

> But I think that it is impossible to completely eliminate the failure
> of the other commands. For example, drop the wrong table.

This kind of thing is heavily application-dependent. For example, you
would likely not care if an operator, who has newly-joined the team in
charge of the maintenance of this data, drops unfortunately a table
which includes logs from 10 years back, and you would very likely care
about a table dropped which has user's login data. My point is that you
need to carefully design the shape of the configuration you would use,
so as any application's admin would be able to cope with it, for example
allowing exclusion filters with regular expressions could be a good idea
to dig into. And also you need to think about it so as it is backward
compatible.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-07-03 01:30:48 Re: Old small commitfest items
Previous Message Michael Paquier 2018-07-03 01:16:50 Re: automatic restore point