Re: Skytools committed without hackers discussion/review

Ühel kenal päeval, K, 2007-10-10 kell 10:10, kirjutas Joshua D. Drake:
> On Wed, 10 Oct 2007 18:33:03 +0300
> "Marko Kreen" <markokr(at)gmail(dot)com> wrote:
>
> > Considering the core operations are now being in active use
> > some 6-7 years, I really fail to see how there can be anything
> > to tweak, unless you are speaking changing naming style.
>
> Well that is the problem right there isn't it? As someone who has
> financed, shipped, developed and tested an integrated Replication
> solution for *years*,

AH, now I see it , and I think I understand your concerns better ;)

> this statement is obvious naivety.

Then you should not feel threatened by including this in contrib

> Your code, may be the most blessed, pristine and bug free code *in your
> environment* but your environment is hardly the only environment out
> there and things *always* come up.

Meaning there will still be market for tried and tested commercially
supported wal-log based replication solutions.

btw, can you publicly discuss how CommandPrompts WAL-based replication
works ?

Does it also also need something similar to snapshot type to do
replication effectively (or else you have to "quess", which portion of
WAL is safe to commit and in what order) or does it somehow come out of
WAL log naturally ?

And how do you map WAL records back to tables/indexes/sequences in slave
databases in an effective manner ?

> > IMHO the core operations are already as stable as PostgreSQL use
> > of MVCC, as the module just exports backend internal state...
> > Current set of functions is the minimal necessary to implement
> > queue operations, there is nothing more to remove.
>
> Having a hard time buying that. MVCC has the pleasure of being tested
> everyday by hundreds of thousands of installations.

that's what he is telling you - this code just exposes to userspace,
what has been tested everyday by hundreds of thousands of installations.

> > We might want to add some helper functions for query generation,
> > but that does not affect core operation.
> >
>
> But it does affect the inclusion argument.

Probably makes it stronger, as we dont want different users to add
slightly different versions of these. And hopefully these will be
discussed on -hackers before final design is committed :)

> > Another thing can can be done is more compact representation for
> > txid_snapshot type, but that also won't affect core operation.
> >
>
> You are starting to bring up things in your own post that may need to
> change before inclusion. This is *exactly* why the code should be
> removed. It wasn't vetted on -hackers, and if it had been we may have
> had a more complete piece of software.

None of these needs to change before inclusion, as they don't change
interfaces. they are either plans for future enchancemants in
implementation (you cant argue that nothing can get into contrib unless
all conceivable future enchancements are already done), or possible new
interfaces to be added in future if needed.

> > I am very happy for txid being in contrib, I'm not arguing against
> > that, but the hint that txid module is something that just freshly
> > popped out of thin air is irking me.
>
> Certainly, I can understand this as you have had a long time to work
> with, develop and mature the code. However it is just out of thin air.
> It doesn't exist except for a very small part of the PostgreSQL world.
>
> It may not be new to you, but it is certainly 100% new to many of the
> long time contributors of this project.
>
> > > I think our two realistic options today are (1) leave the code where
> > > it is, or (2) remove it. While Jan clearly failed to follow the
> > > agreed procedures, I'm not convinced the transgression was severe
> > > enough to justify (2).
> >
> > Thanks for being understanding.
> >
>
> We all try to be :) but I do feel it needs to be removed, pgFoundry is
> the perfect place for this.

We feel that it is may be a generally enabling technology, and hope that
if it is being included in postgreSQL baseline distribution it will
sprout new uses beyound high-performanse replication and queueing, as it
lowers the barriers for making new creative uses of postgreSQL's MVCC
mechanisms by people not very familiar with minute details of
postgreSQL's inner workings.

--------------------
Hannu