Re: sql_drop Event Trigger - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: sql_drop Event Trigger
Date
Msg-id CAFNqd5X4dZLawf70AfS0_6YX0oTHa-5gF7tACTC34sFJpXu8nw@mail.gmail.com
Whole thread Raw
In response to Re: sql_drop Event Trigger  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: sql_drop Event Trigger
List pgsql-hackers
On Wed, Feb 6, 2013 at 12:05 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Feb 6, 2013 at 9:44 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>>> I disagree with that. I don't see why the enclosing event trigger
>>>> shouldn't be aware of all the objects dropped by the command that just
>>>> ran to completion, *including* the effects of any event trigger fired
>>>> recursively or not.
>>>
>>> Well, that could result in some DROP events being reported more than
>>> once, which I assume would be undesirable for someone hoping to use
>>> this for replication.
>>
>> Any command might have an event trigger attached doing a DROP, so that
>> you don't know where to expect it, and it's well possible that in your
>> example both the event triggers have been installed by different tools.
>
> It certainly is; in fact, it's likely.  So let's say that B is a
> replication trigger.  Don't you want it to hear about each drop
> exactly once?  If not, how will you avoid errors when you go to replay
> the events you've captured on another machine?

In this case, the "hygenic" change that we're thinking of making to Slony,
at least initially, is for the trigger to check to see if the table is
replicated,
and raise an exception if it is.

That forces the Gentle User to submit the Slony SET DROP TABLE
command <http://slony.info/documentation/2.1/stmtsetdroptable.html>.

Now, if we stipulate that imposition, then, for this kind of event, it
becomes unnecessary for event triggers to get *overly* concerned about
capturing more about dropping tables.  After all, SET DROP TABLE
already knows how to replicate its action, so what happens, in that
case is:

- User submits SET DROP TABLE  - SET DROP TABLE drops the triggers for the table, cleans out    Slony configuration
surroundingthe table, forwards request    to other nodes
 

- User submits DROP TABLE  - Slony is no longer involved with that table; there's nothing special    anymore about
replicatingthis; perhaps we capture and forward    it via event trigger.
 

I'm not sure if that makes thinking about this easier, I hope so :-).


-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: sql_drop Event Trigger
Next
From: Robert Haas
Date:
Subject: Re: sql_drop Event Trigger