On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
> On 10/10/07, Magnus Hagander <[EMAIL PROTECTED]> 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...

If it is this irreplacable killer feature, it should *not* be in contrib.
It should be in the core backend, and we should be discussing if we can
bend the rules for that. This is the proper forum for discussing that, so
let's bring that question to the table.

Our beta-1 is already fairly broken (the locale stuff on our most
downloaded platform), so perhaps we should pull that one back, put this
stuff in the backend, and try to get a beta2 out ASAP?

Putting it in contrib "just because we were too late to put it in the
backend, but it is reallyi really important for our users" just doesn't
make sense.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to