http://www.slony.info/bugzilla/show_bug.cgi?id=134

Christopher Browne <cbbrowne at ca.afilias.info> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #1 from Christopher Browne <cbbrowne at ca.afilias.info> 2010-06-07 08:35:43 PDT ---
Yep, I had a chat with various people about this at PGCon, and had some
resolutions of outstanding questions.

The trouble with TRUNCATE comes when there are foreign key relationships.  In
the case of circularity, one might find it necessary to submit:

  TRUNCATE a, b, c;

in order to get all three tables emptied.

Supposing that request is submitted, we'd find, logged, 3 TRUNCATE requests
that were captured by ON TRUNCATE triggers.  (I'm assuming here that all 3
tables were replicated.)

I see 4 strategies for implementing the handling of TRUNCATE:

1.  Deny

Basically, we put the same stored function used for "deny_access" onto the ON
TRUNCATE action.

This isn't ideal, but is better than what we have now.

2.  Log truncate, action on subscriber is "TRUNCATE ONLY"

This won't work out in the "TRUNCATE a,b,c;" scenario described earlier, as the
FK is liable to cause each of these truncate requests to fail.

3.  Log truncate...  Try to form sets of successive TRUNCATEs into one request.

This adds substantially to complexity, and there's the question of when to do
the set of truncates:

  a) At the earliest point in the stream, or
  b) At the latest point in the stream.

More thought necessary to see which order is expected to be "compatible."

[Thinking a bit more...  This might well work...  The transaction claims an
exclusive lock on all the tables, so it ought to be possible to, upon seeing a
TRUNCATE, look for all the adjacent TRUNCATE requests in that same transaction.
 The only trouble is how to not bother reprocessing the subsequent TRUNCATE
requests.]

There is still some risk of failure on the subscriber; supposing there are
differences in FK relations there, there is the possibility of everything
rolling back, and replication becoming blocked at this point.

4.  Log the truncates, and, for each one, submit
   TRUNCATE foo CASCADE;

This has merits over all the others:

- It performs TRUNCATE (unlike 1!)
- Guaranteed to work (unlike 2)
- Much simpler than #3
- No risk of getting stuck because of a FK relationship

There's a big scary demerit:

- It'll blindly truncate everything tied to the table being truncated.

I had a chat about this with Rod Taylor and Greg Sabino Mullane at the EDB
dinner; Rod suggested that #4 was the way to go, and I made sure Greg was aware
of the challenge here.

Peter, your thoughts would definitely be valued.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.