Dan Falconer wrote:
> 	DISCLAIMER: I don't know a lot about the internals of Slony, especially when 
> it comes to how records get into the tables within Slony's replication 
> schema.
>
> 	That said, it seems to me that there should be a way to wholly reduce the 
> apparent amount of work involved in maintaining sequences: in sl_sequence, 
> create a column that contains the last value for each of the sequences.  
> Presumably, there would be a process that checks the current value of each 
> sequence... if it determined that the sequence had changed, run an update on 
> the last sequence (for the master), and do whatever it normally did to note 
> that the slaves should update their sequences.
>
> 	I apologize for the amount of vagueness in my reply.  It was quite apparent 
> to me, while attempting to formulate words to express my idea, that I knew 
> very little of the actual inner workings of Slony.  I hope the idea makes 
> sense and doesn't cause any eye-bleeding.  :) 
>   
No problem; I understand what you mean...

There are two problems with that approach:

1.  As Brad mentioned in his followup, this forces there to be Only One
Value for the sequence in flight at any given time.  That doesn't allow
properly handling the case where we have a series of updates thus:

SYNC 452 - seq_a = 121
SYNC 453 - seq_a = 124
SYNC 454 - seq_a = 124
SYNC 455 - seq_a = 125
SYNC 456 - seq_a = 127
SYNC 457 - seq_a = 135
SYNC 458 - seq_a = 124  (And it jumps back to 124, for some reason...)

If the value gets stowed on sl_sequence, and node 5 happens to fall a
bit behind so that we have to apply SYNCs 452 thru 458, we haven't any
place to get those interim values.

The typical usage of a sequence value is to provide values for primary
keys; in that case, losing interim values isn't terribly important.

But sometimes sequences are characterizing the state of something;
rotating between 0 and 1 or otherwise cycling through some small set of
values that actually imply some symbolic meaning.  And we may want that
to be consistent at the end of each SYNC.

This is why the idea isn't good enough.

Then there's problem #2...

2.  If we're continually updating the contents of sl_sequence, then that
means the table will be blowing through dead tuples "like nobody's
business."

That's already a problem with sl_seqlog; making it a problem with
sl_sequence seems to me to worsen things more, notably because it's a
much wider table.

I'm not pointing out the problems to be unkind or anything; the point of
the exercise is to better understand the usage of sl_seqlog.  Finding
worse alternatives   After pointing out enough flaws in various
proposals, however well-baked, inspiration will hopefully strike and
someone may perceive a "non-flawed" approach that we *can* use.