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.
Accordingly, that function isn't supposed to be used in any places
where you cannot avoid its use during recovery of core system indexes.
I am not sure to what extent its use in the TOAST support compromises
that position, but for sure the fact that it's called from
EventTriggerDDLCommandStart has broken the concept completely.
If pg_event_trigger_evtname_index becomes corrupt, you can kiss your
database goodbye, because you have no hope whatsoever of issuing the
commands needed to reindex it.
Maybe it's time to bite the bullet and implement a heapscan-and-sort
code path for systable_beginscan_ordered to use when
ignore_system_indexes is set. But that's a fair amount of work.
The path of least resistance would be to make the event trigger stuff
not depend on this function.
Or maybe we should disable event triggers altogether in standalone mode?
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
