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@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.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