Re: automatic restore point

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>, "Yotsunaga, Naoki" <yotsunaga.naoki@jp.fujitsu.com>, 'Postgres hackers' <pgsql-hackers@postgresql.org>
Date: 2018-10-05T13:26:27Z
Lists: pgsql-hackers

Attachments

On 02/10/2018 00:06, Alvaro Herrera wrote:
> 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).

It looked for a moment that

    isCompleteQuery = (context <= PROCESS_UTILITY_QUERY)

in ProcessUtilitySlow() might be a problem, since that omits
PROCESS_UTILITY_QUERY_NONATOMIC, but it's not actually a problem, since
the commands that run this way (CALL and SET from PL/pgSQL) don't have
event triggers.  But anyway, I propose the attached patch to rephrase
that.  Also some tests that show it all works as expected.

> 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).

I don't see why we couldn't add event triggers on TRUNCATE or other
commands such as DELETE.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Slightly correct context check for event triggers