On 2012-12-06 18:21:09 +0000, Simon Riggs wrote: > On 6 December 2012 00:46, Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Dec 5, 2012 at 6:45 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > >> Yes, but it is also the trigger writers problem. > > > > Maybe to some degree. I don't think that a server crash or something > > like a block-read error is ever tolerable though, no matter how silly > > the user is with their event trigger logic. If we go down that road > > it will be impossible to know whether errors that are currently > > reliable indicators of software or hardware problems are in fact > > caused by event triggers. Of course, if an event trigger causes the > > system to error out in some softer way, that's perfectly fine... > > How are event triggers more dangerous than normal triggers/functions?
Normal triggers aren't run when the catalog is in an in-between state because they aren't run while catalog modifications are taking place. Consider a trigger running before CREATE INDEX CONCURRENTLY (which relies on being the first thing to do database access in a transaction) that does database access. Or a trigger running during a table rewrite that inserts into the intermediary table (pg_rewrite_xxx or whatever they are named). That possibly would lead to a crash because the pg_class entry of that table are suddently gone. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers