On 9/24/2007 12:18 PM, Decibel! wrote:
> On Mon, Sep 24, 2007 at 11:22:42AM -0400, Jan Wieck wrote:
>> On 9/21/2007 6:40 PM, Decibel! wrote:
>> >On Fri, Sep 21, 2007 at 11:50:41AM -0700, David Fetter wrote:
>> >>On Fri, Sep 21, 2007 at 09:44:59PM +0300, Marko Kreen wrote:
>> >>> On 9/20/07, Decibel! <decibel at decibel.org> wrote:
>> >>> > Seeing the complete duplication of txid.sql between Slony and
>> >>> > londiste bugs me, so I'm hoping we can come up with a replacement
>> >>> > for that in core, and the replica-hooks list seems the logical way
>> >>> > to discuss that...
>> >>> 
>> >>> You forgot to give link to list:
>> >>> 
>> >>>  http://pgfoundry.org/mailman/listinfo/replica-hooks-discuss
>> >>> 
>> >>> 
>> >>> Compared of to rest of replica-hooks discussion, this is pretty
>> >>> straightforward affair, not much to discuss here.
>> >
>> >Actually, what I'm really wondering is if a "commit ID" analogous to a
>> >transaction ID but set at commit time (and in order of commits) would
>> >vastly simplify things...
>> 
>> It would simplify things for a single master, multiple slaves system. 
>> But a pure ID won't help a multimaster system at all. If you are 
> 
> Well, we currently don't have any multi-master systems that aren't
> statement-based, so I'd be happy for just having a commit ID right
> now... I suspect that a future multi-master system could still make use
> of a plain commit ID as well (though it'd obviously need something more
> than that).

Unless you have a particular use case in mind, I'd be against such plain 
commit ID right now.

The point is that if we have "something" now, we have to support and 
continue having "that something" in the future. Which will be what? A 
thing that theoretically can make life easier for existing replication 
systems, that already have a solution for not having it in the first 
place. But it will also be a thing that is *in the way* of something 
that might be useful for replication systems we don't have yet, like a 
row based multimaster. The argument then being "we already have x, y and 
z that we need to support; how much more things have to be added to core?".

For Slony-I specifically, we are currently developing version 2.0. This 
version will not be backwards compatible to any Postgres version before 
8.3 because it makes use of the pg_trigger and pg_rewrite changes that 
happened there. This is required because the system catalog mucking done 
in earlier Slony versions had caused endless pain. However, the benefits 
of any kind of "commit ID" that might be coming in 8.4 will not warrant 
such backwards incompatibility again. So I doubt that Slony-I would make 
use of such feature any sooner than when we drop support for 8.3 
somewhere in the distant future.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #