Date: Mon, 1 Oct 2018 19:06:32 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>,
	"Yotsunaga, Naoki" <yotsunaga.naoki@jp.fujitsu.com>,
	'Postgres hackers' <pgsql-hackers@postgresql.org>
Subject: Re: automatic restore point
Message-ID: <20181001220632.7a4jnzph2cwntq6w@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <544ca174-f0a1-fe75-ce74-3625fbc09447@2ndquadrant.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

On 2018-Oct-01, Peter Eisentraut wrote:

> The following appears to work:
> 
> CREATE FUNCTION evt_automatic_restart_point() RETURNS event_trigger
> LANGUAGE plpgsql
> AS $$
> BEGIN
>   PERFORM pg_create_restore_point(tg_tag);
> END
> $$;
> 
> CREATE EVENT TRIGGER automatic_restart_point ON ddl_command_start
>     EXECUTE PROCEDURE evt_automatic_restart_point();
> 
> Are there any concerns about this?

Mumble.

Re-reading the implementation in standard_ProcessUtility, I wonder what
is PROCESS_UTILITY_QUERY_NONATOMIC -- there seems to be a maze through
SPI that determines whether this flag is set or not, which could affect
whether the event trigger is useful.  Are utilities executed through a
procedure detected by event triggers?  If so, then this mechanism seems
good enough to me.  But if there's a way to sneak utility commands (DROP
TABLE) without the event trigger being invoked, then no (and in that
case maybe it's just a bug in procedures and we can still not include
this patch).

(Grepping for "atomic" is unsurprisingly unhelpful.  I really wish we
didn't use plain words as struct member names ...)

On the TRUNCATE case it's a bit annoying that you can't do it with event
triggers -- you have to create individual regular triggers on truncate
for each table (so you probably need yet another event trigger that
creates such triggers).

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services