Re: Use of systable_beginscan_ordered in event trigger patch

Hi,

I don't remember that we fixed that case, I did attach a patch in the
previous email, what do you think?

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Or maybe we should disable event triggers altogether in standalone mode?
>
> Would something as simple as the attached work for doing that? (passes
> make check and I did verify manually that postmaster --single is happy
> with it and skipping Event Triggers).
>
> Regards,
> --
> Dimitri Fontaine
> http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
>
>
> *** a/src/backend/commands/event_trigger.c
> --- b/src/backend/commands/event_trigger.c
> ***************
> *** 567,572 **** EventTriggerDDLCommandStart(Node *parsetree)
> --- 567,585 ----
> EventTriggerData trigdata;
>
> /*
> + * Event Triggers are completely disabled in standalone mode so as not to
> + * prevent fixing a problematic situation.
> + *
> + * To enable Event Triggers in standalone mode we would have to stop using
> + * systable_beginscan_ordered so that it's still possible to rebuild
> + * corrupt indexes (thanks to ignore_system_indexes). One way to do that is
> + * implementing a heapscan-and-sort code path to use when
> + * ignore_system_indexes is set.
> + */
> + if (!IsUnderPostmaster)
> + return;
> +
> + /*
> * We want the list of command tags for which this procedure is actually
> * invoked to match up exactly with the list that CREATE EVENT TRIGGER
> * accepts. This debugging cross-check will throw an error if this

--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support