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