Re: Use of systable_beginscan_ordered in event trigger patch
От | Dimitri Fontaine |
---|---|
Тема | Re: Use of systable_beginscan_ordered in event trigger patch |
Дата | |
Msg-id | m2r4qo1x1g.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Use of systable_beginscan_ordered in event trigger patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > I find $SUBJECT fairly scary, because systable_beginscan_ordered() is > dependent on having a working, non-corrupt index. If you are trying > to run the backend with ignore_system_indexes so that you can rebuild > corrupt indexes, uses of systable_beginscan_ordered() represent places > where you can't turn that off, and are entirely at the mercy of the > indexes being good. Ooops. Didn't see that, thanks for noticing! > Or maybe we should disable event triggers altogether in standalone mode? +1 > I can think of plenty of ways that a broken event trigger could cause > enough havoc that you'd wish there was a way to suppress it, at least > for long enough to drop it again. I fail to see how enabling Event Triggers in standalone mode would help you get out of the situation that lead you there. It's a last resort facility where you want the bare PostgreSQL behavior, I think. Now that you mention it. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: