Re: Use of systable_beginscan_ordered in event trigger patch

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Use of systable_beginscan_ordered in event trigger patch
Дата
Msg-id CA+TgmobO+h=4_gQCbpSgx1vkJB6xgfuVfvgQoEqkuYzO9QUGZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Use of systable_beginscan_ordered in event trigger patch  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Parser Cruft in gram.y
Список pgsql-hackers
On Fri, Dec 14, 2012 at 3:46 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>>> Robert, does that ring a bell to you? I'm going to crawl the archives
>>> tomorrow if not…
>>
>> Yeah, I'm pretty sure you can't set event triggers of any kind on
>> event triggers.  You proposed to allow some stuff that would affect
>> "every command", but I yelled and screamed about that until we got rid
>> of it, 'cuz it just seemed way too dangerous.
>
> I meant about the way the documentation is phrased to introduce the
> example, which is somewhat wrong because not all commands are concerned,
> quite a bunch of them will not be disabled by such a command trigger.
>
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Sooner or later there will be one somewhere in the code path involved
>> in doing a heap_delete on pg_event_trigger, or one of the subsidiary
>> catalogs such as pg_depend, or maybe one that just manages to fire
>> someplace during backend startup, or who knows what.
>
> You're right that we need to be careful here, in ways that I didn't
> foresee. The first thing I can think of is to disable such low level
> events on system catalogs, of course.
>
>> Hence, I want a kill switch for all event triggers that will most
>> certainly work, and the just-committed patch provides one.
>
> We absolutely need that, and running Event Triggers in standalone mode
> seems counter productive to me anyway. That said maybe we need to be
> able to have a per-session "leave me alone" mode of operation. What do
> you think of
>
>    ALTER EVENT TRIGGER DISABLE ALL; -- just tried, no conflict
>
> I don't think we need the ENABLE ALL variant, and it would not be
> symetric anyway as you would want to be able to only enable those event
> triggers that were already enabled before, and it seems to me that
> "cancelling" a statement is best done with "ROLLBACK;" or "ROLLBACK TO
> SAVEPOINT …;".

ISTM that a PGC_SUSER GUC, as I proposed previously, would serve this
need adequately, without the cost of more cruft in gram.y.

Am I wrong?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Assert for frontend programs?
Следующее
От: Любен Каравелов
Дата:
Сообщение: Re: Use gcc built-in atomic inc/dec in lock.c