Re: Last gasp - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Last gasp
Date
Msg-id CA+Tgmoa75QujxzCZC+dj=0+JayGPhJD2kQMDBmbGmmq_HPgHxw@mail.gmail.com
Whole thread Raw
In response to Re: Last gasp  (Hannu Krosing <hannu@krosing.net>)
Responses Re: Last gasp  (Hannu Krosing <hannu@krosing.net>)
List pgsql-hackers
On Thu, Apr 5, 2012 at 2:46 PM, Hannu Krosing <hannu@krosing.net> wrote:
> To me it looked like the scope of the patch started to suddenly expand
> exponentially a few days ago from a simple COMMAND TRIGGERS, which would
> have finally enabled trigger-based or "logical" replication systems to
> do full replication to something recursive which would attempt to cover
> all weird combinations of commands triggering other commands for which
> there is no real use-case in view, except a suggestion "don't do it" :)
>
> The latest patch (v18) seemed quite ok for its original intended
> purpose.

OK, so here we go, rehashing the discussion we already had on thread A
on thread B.  The particular issue you are mentioning there was not
the reason that patch isn't going to end up in 9.2.  If the only thing
the patch had needed was a little renaming and syntax cleanup, I would
have done it myself (or Dimitri would have) and I would have committed
it.  That is not the problem, or at least it's not the only problem.
There are at least two other major issues:

- The patch as posted fires triggers at unpredictable times depending
on which command you're executing.  Some things that are really
sub-commands fire triggers anyway as if they were toplevel commands;
others don't; whether or not it happens in a particular case is
determined by implementation details rather than by any consistent
principle of operation.  In the cases where triggers do fire, they
don't always fire at the same place in the execution sequence.

- The patch isn't safe if the triggers try to execute DDL on the
object being modified.  It's not exactly clear what misbehavior will
result in every case, but it is clear that that it hasn't really been
thought about.

Now, if anyone who was actually following the conversation thought
these things were not problems, they could have written back to the
relevant thread and said, hey, I don't mind if the trigger firing
behavior changes every time someone does any refactoring of our
badly-written DDL code and if the server blows up in random ways when
someone does something unexpected in the trigger that's OK with me
too.  Maybe not surprisingly, no one said that.  Two people wrote into
that thread after my latest round of reviewing and both of them
disagreed with only minor points of my review, and we had a technical
discussion about those issues.  But showing up after the fact and
acting as if there were no serious issues found during that review is
either disingenuous or a sign that you didn't really read the thread.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Last gasp
Next
From: Robert Haas
Date:
Subject: Re: Last gasp