Andrew Sullivan <ajs at crankycanuck.ca> writes:
> On Mon, Sep 22, 2008 at 02:45:55PM -0700, Jennifer Spencer wrote:
>> Hi Aaron,
>>
>> It would be pretty easy to check the truncate behavior by running another 
>> slon process, with a test cluster and table, and trying it out.  I myself 
>> don't know if "truncate" is something Slony explicitly supports (and I am 
>> guessing not).
>
> Nope, it doesn't.  In 8.4 there's a proposal for ON TRUNCATE triggers, though.

It's implemented in 8.4, and has been committed to HEAD.

Simon Riggs was kind enough to submit a sample patch for Slony-I to
implement these triggers, which does pass the "does that kinda work"
test.

The reason it hasn't gotten committed is that there's a bit of a
puzzle as to how to deal with cases like:

  TRUNCATE t1, t2, t3, t4;
   or
  TRUNCATE t1 CASCADE;

These would both (potentially!) lead to truncating several tables, and
firing the truncate triggers several times.  For those truncates to
*WORK*, on subscribers, we need to be able to merge them into a single
request, and nobody has proposed how we might do *that.*

As a "first draft," I could see either:

 a) Ruling out TRUNCATE by putting "deny access"-like functions onto
    ON CASCADE triggers on all replicated tables (on all nodes!)

 b) Taking the "primitive" approach of accepting TRUNCATE, capturing
    the table ID, and propagating that.

    This risks breaking if you submit one of the two sample queries I
    described earlier, though.
-- 
output = reverse("ofni.secnanifxunil" "@" "enworbbc")
http://linuxfinances.info/info/
Would-be National Mottos:
USA: "There oughta' be a law!"