Re: Skytools committed without hackers discussion/review - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: Skytools committed without hackers discussion/review
Date
Msg-id e51f66da0710100527i3022c9ban67ccacad45547b60@mail.gmail.com
Whole thread Raw
In response to Re: Skytools committed without hackers discussion/review  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Skytools committed without hackers discussion/review
Re: Skytools committed without hackers discussion/review
List pgsql-hackers
On 10/10/07, Magnus Hagander <magnus@hagander.net> wrote:
> All objections have been procedural, AFICS.

Lets not talk about mistakes we made for a moment.

And I agree with the rest of the objections in general. But I'd
like to summarise why I still hope the exception can be made
even this late.

This is directly related to attitude to the first submission to 8.2:
"unless Slony uses it we are not interested".  Now is the only
moment which won't come again in several years that it's possible
to unify txid handling in Slony and Skytools and also make the
functionality available to broader public.

This due to the fact that Slony 2.0 which will be released with 8.3
will not support PostgreSQL version lower then 8.3.

Yes, we realized the opportunity too late and now it's question
if PostgreSQL is flexible enough to react to this.

Note that rejection now does not cause any big problems to either
Slony and Skytools, we will keep our internal versions of the module,
invisible to anybody else.

But the potential use of the module is huge - it's killer feature is
that it allows to implement high-performance multi-reader / multi-writer
queues inside database.  Well, I know this sounds unimpressive, queues
do not belong to standard toolbox when doing database developement.
And those who have tried to implement them, carry a "avoid at any cost" tag,
because thus far there has not been a way to implement robust and
well-perfoming queue inside general-purpose database.

Now txid can change that.  E.g. in Skype, it has become irreplaceable
tool for coordinating work between several databases.  Here we are
probably going overboard with usage of queues...

-- 
marko


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Locale + encoding combinations
Next
From: Tom Lane
Date:
Subject: Re: Locale + encoding combinations