Jim C. Nasby wrote:
> On Wed, May 31, 2006 at 09:33:04PM +0000, Christopher Browne wrote:
>   
>> Based on the discussion of the last day or so, we really need to see
>> about getting version 1.2 released.
>>
>> As far as I can tell, all of the issues Rod pointed out are resolved in
>> CVS HEAD, so that 1.2 should seriously diminish the need for
>> "super-skilled staff" when setting up Very Large Instances.  Some issues
>> do not disappear; there will still be long running transactions that
>> cause some inconvenience, which is, to a great degree, an unavoidable
>> problem.  But we can certainly get rid of a bunch of the "misfeature" cases.
>>     
>
> There's some ideas in
> http://archives.postgresql.org/pgsql-hackers/2006-02/msg01164.php that
> could potentially eliminate the issues associated with long-running
> transactions, should someone want to push for it. In a nutshell, the
> idea is to provide a means for a transaction to list a set of tables
> that it will never touch (again). Vacuum can then take that into account
> when figuring out what the minimum XID that has to be kept in a table
> is.
>   
Those ideas are potentially relevant to improving the behaviour of VACUUM...

I don't see them being particularly relevant to Slony-I, notably because
we'll need to apply all changes in sl_log_1 even if we could prove that
some weren't going to ever be visible on the subscriber, because we
*need* to apply them in the compatible order.  If we try not to do so,
there's the risk of an update like the following one failing:

update t1 set id = 3 where id = 1;
update t1 set id = 1 where id = 2;
update t1 set id = 2 where id = 3;

This is the classic case of "swapping" entries; skipping steps results
in the update failing.

There still do exist cases where transactions get held open for long
periods of time, while COPY_SET is running; there seem to me to be a
couple of ways of addressing this:

1.  Doing one table at a time would minimize the time a transaction was
left open. 

Rod has made the argument to me that it would be valuable if tables were
only loosely tied to sets; at subscription time, tables would get added
one by one, independently, each as separate transactions on
provider+subscriber.

2.  There *might* be some cleverness about closing out transactions on
the provider so that the subscription process for 4 tables would
represent 4 transactions on the provider.

Either way, it would substantially complicate the subscription process :-(.