Simon Riggs <simon at 2ndquadrant.com> writes:
> Enclosed is a trial patch for Slony CVS HEAD to implement replication
> using Truncate Triggers. (A patch for truncate triggers has just been
> submitted to pgsql-patches at postgresql.org)
>
> This compiles, but I haven't tested this further. No docs.
>
> I'm hoping for some review comments and then assistance with building
> tests.
>
> Implementation seeks to minimise changes to existing Slony message
> output...

I finally got around to reviewing this; the changes seem to be pretty
sound, with a pretty big caveat discussed at the end...

Assumption (which I validated in our conversation today): We need to
add the very same logtrigger() function to an "ON TRUNCATE" trigger.

Obvious extra bits of implementation:
- Need for function alterTableAddTriggers() in
  src/backend/slony1_funcs.sql to consider adding the ON TRUNCATE
  trigger.

  At first blush, it looks like this needs to be in an
  exception-handling block, so that we can fairly transparently
  accomodate the issue of whether or not the backend supports ON
  TRUNCATE triggers.

  Similar changes to alterTableDropTriggers()...

- Need to add documentation; it may not need to be extensive, but just
  declare that we now support TRUNCATE, if the origin node does.

- Testing: It should be easy enough to make a copy of the base
  "test1", and throw in a TRUNCATE and ensure that works.

  Making this torturous would involve something like:
   BEGIN;
     INSERT [A values] into t_table;
     TRUNCATE t_table;
     INSERT [B values] into t_table;
     TRUNCATE t_table;
     INSERT [C values] into t_table;
     TRUNCATE t_table;
     INSERT [D values] into t_table;
   COMMIT;

We of course need for t_table to contain "set D" of values...

There is, however, a significant complication to be had, in that there
are two special forms of TRUNCATE that can take place:

  a) TRUNCATE [list of multiple tables]

  b) TRUNCATE [tables] CASCADE

The TRUNCATE may need to be reverted into a DELETE if a foreign key
constraint causes TRUNCATE to fail.

And if we have multiple TRUNCATEs that came in, consecutively, we may
need to apply them as a single request in order to avoid running afoul
of foreign key restrictions that mandated the multiplicity in the
first place.  I sure hope that the multiple TRUNCATES would be
consecutive in sl_log_N...

This may mandate having the "peephole optimization" that we have the
ability to group multiple TRUNCATE requests together...  That's
potentially a rather significant complication...
-- 
"cbbrowne","@","linuxfinances.info"
http://linuxfinances.info/info/advocacy.html
Rules of  the Evil Overlord #20. "Despite  its proven stress-relieving
effect, I  will not  indulge in maniacal  laughter. When  so occupied,
it's too  easy to miss  unexpected developments that a  more attentive
individual could adjust to accordingly."
<http://www.eviloverlord.com/>