From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "Yotsunaga, Naoki" <yotsunaga(dot)naoki(at)jp(dot)fujitsu(dot)com>, 'Postgres hackers' <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: automatic restore point |
Date: | 2018-10-01 03:34:23 |
Message-ID: | 20181001033423.xtc7jckr74good2n@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-Sep-30, Michael Paquier wrote:
> On Fri, Sep 28, 2018 at 09:13:17PM +0200, Peter Eisentraut wrote:
> > I think this should be done using event triggers. Right now, you just
> > have it hardcoded to TRUNCATE and DROP TABLE, which seems somewhat
> > arbitrary. With event triggers, you have the full flexibility to do
> > what you want. You can pick which commands to apply it to, you can log
> > the LSN, you can create restore points, etc.
>
> I still unfortunately don't see what this patch brings more that you
> cannot do. Event triggers are particularly useful in this prospective,
> so I am marking the patch as rejected.
I don't see it as clear cut as all that ... particularly considering
that a useful event trigger runs *after* the DDL command in question has
already written all its WAL, so such a restore point would be completely
useless. (Or are ddl_command_start event triggers useful enough?)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-10-01 03:35:46 | Re: automatic restore point |
Previous Message | Tom Lane | 2018-10-01 02:49:18 | Re: executor relation handling |