From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TABLE ... NOREWRITE option |
Date: | 2012-12-06 18:31:37 |
Message-ID: | 20121206183137.GA20926@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2012-12-06 18:21:09 +0000, Simon Riggs wrote:
> On 6 December 2012 00:46, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Wed, Dec 5, 2012 at 6:45 PM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2012-12-06 18:34:08 | Re: autovacuum truncate exclusive lock round two |
Previous Message | Tom Lane | 2012-12-06 18:27:12 | Re: How to check whether the row was modified by this transaction before? |