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 <dimi...@2ndquadrant.fr> writes: > Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
