Thread: Open source databases '60 per cent cheaper'
At leas Enterprise DB is mentioned: http://www.itweek.co.uk/vnunet/news/2168971/open-source-databases-slice -- Med venlig hilsen Kaare Rasmussen, Jasonic Jasonic Telefon: +45 3816 2582 Nordre Fasanvej 12 2000 Frederiksberg Email: kaare@jasonic.dk
On Tue, 2006-11-21 at 16:45 +0100, Kaare Rasmussen wrote: > At leas Enterprise DB is mentioned: > > http://www.itweek.co.uk/vnunet/news/2168971/open-source-databases-slice Too bad EnterpriseDB isn't Open Source. Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Tue, Nov 21, 2006 at 07:58:22AM -0800, Joshua D. Drake wrote: > On Tue, 2006-11-21 at 16:45 +0100, Kaare Rasmussen wrote: > > At leas Enterprise DB is mentioned: > > > > http://www.itweek.co.uk/vnunet/news/2168971/open-source-databases-slice > > Too bad EnterpriseDB isn't Open Source. Too bad, also, that the word "PostgreSQL" doesn't appear anywhere in that article. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
> Too bad, also, that the word "PostgreSQL" doesn't appear anywhere in > that article. OK, so, this article does a little better: http://www.internetnews.com/dev-news/article.php/3644946 -- Med venlig hilsen Kaare Rasmussen, Jasonic Jasonic Telefon: +45 3816 2582 Nordre Fasanvej 12 2000 Frederiksberg Email: kaare@jasonic.dk
On Tue, 2006-11-21 at 14:32 -0500, Andy Astor wrote: > For the record, Josh, we don't claim to be open source. Our policy and > licensing is spelled out on the web site, and will be even clearer when > we revamp the site in the next few weeks. If you've seen representations > by EnterpriseDB to the contrary, just let me know (off the mailing list, > please), and we'll attend to it during our refresh. Just about every PR you do, and multiple links on your website. :). I am sending specifics off list. Sincerely, Joshua D. Drake > Thanks for your > help. > > Andy > > > -----Original Message----- > > From: Joshua D. Drake [mailto:jd@commandprompt.com] > > Sent: Tuesday, November 21, 2006 2:20 PM > > To: Andy Astor > > Cc: David Fetter; Kaare Rasmussen; pgsql-advocacy@postgresql.org > > Subject: RE: [pgsql-advocacy] Open source databases '60 per cent > cheaper' > > > > > > > In terms of our open source-ness, we follow the lead of many other > > > PostgreSQL products -- including Command Prompt's Replicator -- with > an > > > "available source" approach, in which paying customers may access > and > > > modify EnterpriseDB code, but redistribution is not permitted. > > > > *ahem*, Command Prompt does not state that Replicator is Open Source. > > EnterpriseDB states that it is Open Source, which is false. > > > > > > Sincerely, > > > > Joshua D. Drake > > > > > > > > > > -- Andy > > > > > > Andy Astor, CEO > > > EnterpriseDB Corporation > > > 33 Wood Avenue South, 3rd Floor > > > Iselin, NJ 08830 USA > > > +1.732.331.1310 Direct > > > +1.732.331.1301 Fax > > > www.enterprisedb.com > > > > > > > -----Original Message----- > > > > From: pgsql-advocacy-owner@postgresql.org [mailto:pgsql-advocacy- > > > > owner@postgresql.org] On Behalf Of David Fetter > > > > Sent: Tuesday, November 21, 2006 11:09 AM > > > > To: Joshua D. Drake > > > > Cc: Kaare Rasmussen; pgsql-advocacy@postgresql.org > > > > Subject: Re: [pgsql-advocacy] Open source databases '60 per cent > > > cheaper' > > > > > > > > On Tue, Nov 21, 2006 at 07:58:22AM -0800, Joshua D. Drake wrote: > > > > > On Tue, 2006-11-21 at 16:45 +0100, Kaare Rasmussen wrote: > > > > > > At leas Enterprise DB is mentioned: > > > > > > > > > > > > > http://www.itweek.co.uk/vnunet/news/2168971/open-source-databases- > > > > slice > > > > > > > > > > Too bad EnterpriseDB isn't Open Source. > > > > > > > > Too bad, also, that the word "PostgreSQL" doesn't appear anywhere > in > > > > that article. > > > > > > > > Cheers, > > > > D > > > > -- > > > > David Fetter <david@fetter.org> http://fetter.org/ > > > > phone: +1 415 235 3778 AIM: dfetter666 > > > > Skype: davidfetter > > > > > > > > Remember to vote! > > > > > > > > ---------------------------(end of > > > broadcast)--------------------------- > > > > TIP 9: In versions below 8.0, the planner will ignore your desire > to > > > > choose an index scan if your joining column's datatypes do > not > > > > match > > > > > -- > > > > === The PostgreSQL Company: Command Prompt, Inc. === > > Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 > > Providing the most comprehensive PostgreSQL solutions since 1997 > > http://www.commandprompt.com/ > > > > Donate to the PostgreSQL Project: > http://www.postgresql.org/about/donate > > > > > > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
> In terms of our open source-ness, we follow the lead of many other > PostgreSQL products -- including Command Prompt's Replicator -- with an > "available source" approach, in which paying customers may access and > modify EnterpriseDB code, but redistribution is not permitted. *ahem*, Command Prompt does not state that Replicator is Open Source. EnterpriseDB states that it is Open Source, which is false. Sincerely, Joshua D. Drake > > -- Andy > > Andy Astor, CEO > EnterpriseDB Corporation > 33 Wood Avenue South, 3rd Floor > Iselin, NJ 08830 USA > +1.732.331.1310 Direct > +1.732.331.1301 Fax > www.enterprisedb.com > > > -----Original Message----- > > From: pgsql-advocacy-owner@postgresql.org [mailto:pgsql-advocacy- > > owner@postgresql.org] On Behalf Of David Fetter > > Sent: Tuesday, November 21, 2006 11:09 AM > > To: Joshua D. Drake > > Cc: Kaare Rasmussen; pgsql-advocacy@postgresql.org > > Subject: Re: [pgsql-advocacy] Open source databases '60 per cent > cheaper' > > > > On Tue, Nov 21, 2006 at 07:58:22AM -0800, Joshua D. Drake wrote: > > > On Tue, 2006-11-21 at 16:45 +0100, Kaare Rasmussen wrote: > > > > At leas Enterprise DB is mentioned: > > > > > > > > http://www.itweek.co.uk/vnunet/news/2168971/open-source-databases- > > slice > > > > > > Too bad EnterpriseDB isn't Open Source. > > > > Too bad, also, that the word "PostgreSQL" doesn't appear anywhere in > > that article. > > > > Cheers, > > D > > -- > > David Fetter <david@fetter.org> http://fetter.org/ > > phone: +1 415 235 3778 AIM: dfetter666 > > Skype: davidfetter > > > > Remember to vote! > > > > ---------------------------(end of > broadcast)--------------------------- > > TIP 9: In versions below 8.0, the planner will ignore your desire to > > choose an index scan if your joining column's datatypes do not > > match > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
>
> I know EnterpriseDB is trying to have PostgreSQL mentioned in all their
> articles, but I supposed becuase it is an article that includes all open
> source databases (or based on open source databases like EnterpriseDB),
> it wasn't possible.
Honestly, I applaud the EnterpriseDB PR machine, and there is no reason
they should have to provide a mention to PostgreSQL. If they choose to,
I thank them as a community member. If not, it is their product and I
wish them the best.
However what does need to stop is the false statement that EnterpriseDB
is Open Source.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
David Fetter wrote: > On Tue, Nov 21, 2006 at 07:58:22AM -0800, Joshua D. Drake wrote: > > On Tue, 2006-11-21 at 16:45 +0100, Kaare Rasmussen wrote: > > > At leas Enterprise DB is mentioned: > > > > > > http://www.itweek.co.uk/vnunet/news/2168971/open-source-databases-slice > > > > Too bad EnterpriseDB isn't Open Source. > > Too bad, also, that the word "PostgreSQL" doesn't appear anywhere in > that article. I know EnterpriseDB is trying to have PostgreSQL mentioned in all their articles, but I supposed becuase it is an article that includes all open source databases (or based on open source databases like EnterpriseDB), it wasn't possible. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: > > > > > I know EnterpriseDB is trying to have PostgreSQL mentioned in all their > > articles, but I supposed because it is an article that includes all open > > source databases (or based on open source databases like EnterpriseDB), > > it wasn't possible. > > Honestly, I applaud the EnterpriseDB PR machine, and there is no reason > they should have to provide a mention to PostgreSQL. If they choose to, > I thank them as a community member. If not, it is their product and I > wish them the best. EnterpriseDB tries to get PostgreSQL mentioned if possible. There are strong ethical and business reasons to do that. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Tue, 2006-11-21 at 15:56 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> >
> > >
> > > I know EnterpriseDB is trying to have PostgreSQL mentioned in all their
> > > articles, but I supposed because it is an article that includes all open
> > > source databases (or based on open source databases like EnterpriseDB),
> > > it wasn't possible.
> >
> > Honestly, I applaud the EnterpriseDB PR machine, and there is no reason
> > they should have to provide a mention to PostgreSQL. If they choose to,
> > I thank them as a community member. If not, it is their product and I
> > wish them the best.
>
> EnterpriseDB tries to get PostgreSQL mentioned if possible. There are
> strong ethical and business reasons to do that.
I am not suggesting they don't. I was just saying from my perspective I
didn't have a problem if they did, or didn't. My only complaint is being
addressed off list :)
Sincerely,
Joshua D. Drake
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Tue, 2006-11-21 at 11:21 -0800, Joshua D. Drake wrote: > However what does need to stop is the false statement that EnterpriseDB > is Open Source. We need to differentiate between statements made by journalists and claims made by companies. Anyway, I'm very interested in getting Synchronous Replication into PostgreSQL 8.3. Can I gauge your interest in making Mammoth Replicator Open Source to assist with that project? I'd be very happy to work with you in an open manner on that. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Simon Riggs wrote: > On Tue, 2006-11-21 at 11:21 -0800, Joshua D. Drake wrote: > > > However what does need to stop is the false statement that EnterpriseDB > > is Open Source. > > We need to differentiate between statements made by journalists and > claims made by companies. > > Anyway, I'm very interested in getting Synchronous Replication into > PostgreSQL 8.3. Can I gauge your interest in making Mammoth Replicator > Open Source to assist with that project? I'd be very happy to work with > you in an open manner on that. Mammoth Replicator is not synchronous anyway ... -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Wed, 2006-11-22 at 10:44 -0300, Alvaro Herrera wrote: > Simon Riggs wrote: > > On Tue, 2006-11-21 at 11:21 -0800, Joshua D. Drake wrote: > > > > > However what does need to stop is the false statement that EnterpriseDB > > > is Open Source. > > > > We need to differentiate between statements made by journalists and > > claims made by companies. > > > > Anyway, I'm very interested in getting Synchronous Replication into > > PostgreSQL 8.3. Can I gauge your interest in making Mammoth Replicator > > Open Source to assist with that project? I'd be very happy to work with > > you in an open manner on that. > > Mammoth Replicator is not synchronous anyway ... That's a shame. I thought we might be able get a head start in that way. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Hi, Simon Riggs wrote: >> Mammoth Replicator is not synchronous anyway ... > > That's a shame. I thought we might be able get a head start in that way. Huh? Why should that be a shame? Do you have anything better to propose? Maybe you can get away with Sequoia? Or support my efforts with Postgres-R? Regards Markus
On Wed, 2006-11-22 at 15:28 +0100, Markus Schiltknecht wrote: > Simon Riggs wrote: > >> Mammoth Replicator is not synchronous anyway ... > > > > That's a shame. I thought we might be able get a head start in that way. > > Huh? Why should that be a shame? Because I wanted it to be synchronous and it is not... > Do you have anything better to propose? On -hackers, I think, but not yet. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
On Wed, 2006-11-22 at 15:21 +0000, Simon Riggs wrote:
> On Wed, 2006-11-22 at 15:28 +0100, Markus Schiltknecht wrote:
>
> > Simon Riggs wrote:
> > >> Mammoth Replicator is not synchronous anyway ...
> > >
> > > That's a shame. I thought we might be able get a head start in that way.
> >
> > Huh? Why should that be a shame?
>
> Because I wanted it to be synchronous and it is not...
In theory, it wouldn't be too difficult (especially once 1.8 is done) to
make Replicator Synchronous. We haven't worked out all the gory details
but it is certainly plausible.
But to be honest, the demand for Synchronous is far less than the hype.
Sincerely,
Joshua D. Drake
>
> > Do you have anything better to propose?
>
> On -hackers, I think, but not yet.
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Simon Riggs wrote: > On Wed, 2006-11-22 at 10:44 -0300, Alvaro Herrera wrote: >> Simon Riggs wrote: >>> On Tue, 2006-11-21 at 11:21 -0800, Joshua D. Drake wrote: >>> >>>> However what does need to stop is the false statement that EnterpriseDB >>>> is Open Source. >>> We need to differentiate between statements made by journalists and >>> claims made by companies. >>> >>> Anyway, I'm very interested in getting Synchronous Replication into >>> PostgreSQL 8.3. Can I gauge your interest in making Mammoth Replicator >>> Open Source to assist with that project? I'd be very happy to work with >>> you in an open manner on that. >> Mammoth Replicator is not synchronous anyway ... > > That's a shame. I thought we might be able get a head start in that way. > Have you looked at PGCluster? - Synchronous multi master replication It is listed at pgFoundry -- Shane Ambler pgSQL@007Marketing.com Get Sheeky @ http://Sheeky.Biz
On Thu, 2006-11-23 at 03:30 +1030, Shane Ambler wrote:
> Simon Riggs wrote:
> > On Wed, 2006-11-22 at 10:44 -0300, Alvaro Herrera wrote:
> >> Simon Riggs wrote:
> >>> On Tue, 2006-11-21 at 11:21 -0800, Joshua D. Drake wrote:
> >>>
> >>>> However what does need to stop is the false statement that EnterpriseDB
> >>>> is Open Source.
> >>> We need to differentiate between statements made by journalists and
> >>> claims made by companies.
> >>>
> >>> Anyway, I'm very interested in getting Synchronous Replication into
> >>> PostgreSQL 8.3.
On a side note to this.. you said *into*.. my understanding is the
policy of the community is *no* replication is in core.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Hi, Joshua D. Drake wrote: > On a side note to this.. you said *into*.. my understanding is the > policy of the community is *no* replication is in core. I don't think that policy is written in stone. But for a replication solution to go into core, it should better cover a lot of use cases, i.e. for sure sync *and* async replication. Regards Markus
On Wed, 2006-11-22 at 18:21 +0100, Markus Schiltknecht wrote:
> Hi,
>
> Joshua D. Drake wrote:
> > On a side note to this.. you said *into*.. my understanding is the
> > policy of the community is *no* replication is in core.
>
> I don't think that policy is written in stone. But for a replication
> solution to go into core, it should better cover a lot of use cases,
> i.e. for sure sync *and* async replication.
Perhaps we should re-read the archives. It has been a pretty solid
policy for *years* and it comes up before every release and it always
comes back to:
PostgreSQL doesn't ship a integrated replication solution, BECAUSE not
any one replication solution can fit the need.
Sincerely,
Joshua D. Drake
>
> Regards
>
> Markus
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Hi, Joshua D. Drake wrote: > PostgreSQL doesn't ship a integrated replication solution, BECAUSE not > any one replication solution can fit the need. Yes, that's what I'm saying. Please do not mix cause and effect: no replication solution got into core because none fit all the needs. It's not that we have a policy stating that we don't want any replication solution in core. What could possibly be the reasons for such a policy? Regards Markus
On Wed, 2006-11-22 at 09:30 -0800, Joshua D. Drake wrote:
> On Wed, 2006-11-22 at 18:21 +0100, Markus Schiltknecht wrote:
> > Hi,
> >
> > Joshua D. Drake wrote:
> > > On a side note to this.. you said *into*.. my understanding is the
> > > policy of the community is *no* replication is in core.
> >
> > I don't think that policy is written in stone. But for a replication
> > solution to go into core, it should better cover a lot of use cases,
> > i.e. for sure sync *and* async replication.
>
> Perhaps we should re-read the archives. It has been a pretty solid
> policy for *years* and it comes up before every release and it always
> comes back to:
>
> PostgreSQL doesn't ship a integrated replication solution, BECAUSE not
> any one replication solution can fit the need.
>
I always got the impression that it had more to do with whether it
needed to be in core to work or not.
If there is some great replication solution that a lot of people need
and it will only work with a change to core, that change might make it
in.
However, there may not be nifty syntax changes nor GUCs in core to
support a specific implementation of a replicator.
Regards,
Jeff Davis
On Wed, 2006-11-22 at 18:42 +0100, Markus Schiltknecht wrote:
> Hi,
>
> Joshua D. Drake wrote:
> > PostgreSQL doesn't ship a integrated replication solution, BECAUSE not
> > any one replication solution can fit the need.
>
> Yes, that's what I'm saying.
>
> Please do not mix cause and effect: no replication solution got into
> core because none fit all the needs. It's not that we have a policy
> stating that we don't want any replication solution in core. What could
> possibly be the reasons for such a policy?
Because there will never be a solution that can fit the need?
Slony and replicator are only similar in that they both are asynchronous
master-slave solutions, other than that, we are vastly different and
serve very different needs.
PgCluster would be a good choice for specific workloads but is a bad
choice for many workloads.
uni/cluster is fine if you want a web app and no database logic.
The list goes on, and on.
Sincerely,
Joshua D. Drake
>
> Regards
>
> Markus
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
> If there is some great replication solution that a lot of people need
> and it will only work with a change to core, that change might make it
> in.
>
> However, there may not be nifty syntax changes nor GUCs in core to
> support a specific implementation of a replicator.
There is definitely another reason though :). Adding a replication
solution that is integrated *will* increase development overhead in
terms of support.
Replication touches (alot) of places.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Wed, 2006-11-22 at 10:07 -0800, Joshua D. Drake wrote:
> > If there is some great replication solution that a lot of people need
> > and it will only work with a change to core, that change might make it
> > in.
> >
> > However, there may not be nifty syntax changes nor GUCs in core to
> > support a specific implementation of a replicator.
>
> There is definitely another reason though :). Adding a replication
> solution that is integrated *will* increase development overhead in
> terms of support.
>
> Replication touches (alot) of places.
>
Yes, you're absolutely right.
However, hypothetically, if there was a great replication solution that
helped a lot of people, and it needed some changes to core, I don't
think the patch would be rejected as long as:
(1) The changes are as minimal as possible
(2) The changes are applicable to an entire class of replication, not
just a single implementation
Regards,
Jeff Davis
On Wed, Nov 22, 2006 at 06:21:49PM +0100, Markus Schiltknecht wrote:
> I don't think that policy is written in stone. But for a replication
> solution to go into core, it should better cover a lot of use cases,
> i.e. for sure sync *and* async replication.
Some time ago, I set up a project on pgfoundry to try to work out
what those cases are. So far, exactly one person has sent anything
to the list about it. There were two messages copied to that list
just in the last day, though.
Anyway, I hereby re-affirm my commitment to try to write down what we
are trying to achieve, if I can get anyone to tell me what that is.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
If they don't do anything, we don't need their acronym.
--Josh Hamilton, on the US FEMA
On Nov 22, 2006, at 11:00 AM, Shane Ambler wrote: > Simon Riggs wrote: >> On Wed, 2006-11-22 at 10:44 -0300, Alvaro Herrera wrote: >>> Simon Riggs wrote: >>>> Anyway, I'm very interested in getting Synchronous Replication >>>> into PostgreSQL 8.3. Can I gauge your interest in making Mammoth >>>> Replicator >>>> Open Source to assist with that project? I'd be very happy to >>>> work with >>>> you in an open manner on that. >>> Mammoth Replicator is not synchronous anyway ... >> That's a shame. I thought we might be able get a head start in >> that way. > > Have you looked at PGCluster? - Synchronous multi master replication The downside to pgCluster (and the synchronous pgpool replication as well) is that it's statement-based. That means something like INSERT INTO table VALUES( ..., now(), ... ); Doesn't work right at all. Continuent has statement-based replication that handles common cases (like now() and random()), but it doesn't handle everything (and it's limited to JDBC connections). I'll agree with Josh Drake that the demand for synchronous replication isn't as great as the hype (or the demand for async), but it definitely does exist. Regarding putting stuff in core, ISTR a group was setup on pgFoundry to discuss what features could be added to core to help various replication systems (such as being able to put triggers on DDL), but I don't know if anything every came of it. -- Jim Nasby jim.nasby@enterprisedb.com EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On 11/24/06, Jim Nasby <jim.nasby@enterprisedb.com> wrote: > The downside to pgCluster (and the synchronous pgpool replication as > well) is that it's statement-based. That means something like > > INSERT INTO table VALUES( ..., now(), ... ); > > Doesn't work right at all. Umm, as this is the second incorrect statement you've made about PGCluster, perhaps you really should spend some time reading the docs before posting. Just for the record, PGCluster does support proper replication of now(). > I'll agree with Josh Drake that the demand for synchronous > replication isn't as great as the hype (or the demand for async), but > it definitely does exist. Agreed. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
Hi, Jim, Jim Nasby wrote: > The downside to pgCluster (and the synchronous pgpool replication as > well) is that it's statement-based. That means something like > > INSERT INTO table VALUES( ..., now(), ... ); > > Doesn't work right at all. Hmm, I guess that the new RETURNING feature of PostgreSQL 8.2 can help with this problem. Regards, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org
On Sun, Nov 26, 2006 at 04:09:20PM -0500, Jonah H. Harris wrote:
>
> Umm, as this is the second incorrect statement you've made about
> PGCluster, perhaps you really should spend some time reading the docs
> before posting. Just for the record, PGCluster does support proper
> replication of now().
It's sort of irrelevant whether there are tricks to solve things like
now(), because the central problem is that of shipping statements
around.
The problem with statement-based replication is that it can't provide
generic support for replication of those statements that are
sensitive to state. For example, a stored procedure that contains a
call to CURRENT_TIMESTAMP will not be replicated perfectly.
(PGCluster, in a test that I ran some time ago, replicated the call
to the stored procedure. That means that the value of
CURRENT_TIMESTAMP could differ on different members of the group.)
Unless you put a complete interpreter and planner in between the
clients and the replicas, this is a simple, in-principle limitation
of statement based replication. If you _do_ put a complete
interpreter in the way, then you have created a single point of
failure. This is why synchronous replication is hard. (The other
trick, of course, is network-based IPC, which is what PGCluster-II is
aiming at. I'm eagerly awaiting results!)
None of this is to say that PGCluster isn't useful for some purposes.
But I don't see any value in pretending that PGCluster can ever
represent a completely generic multimaster system, when it has such
an important limitation. It is certainly the best available
multimaster system at the moment, and I can think of applications
where it would probably be a very good choice for use.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
"The year's penultimate month" is not in truth a good way of saying
November.
--H.W. Fowler
On Mon, 2006-11-27 at 11:39 +0100, Markus Schaber wrote: > Hmm, I guess that the new RETURNING feature of PostgreSQL 8.2 can help > with this problem. I don't see how. The basic problem is that SQL is nondeterministic in general; you can't safely assume that evaluating the same sequence of SQL statements on all nodes will yield the same final database state. -Neil
neilc@samurai.com (Neil Conway) writes:
> On Mon, 2006-11-27 at 11:39 +0100, Markus Schaber wrote:
>> Hmm, I guess that the new RETURNING feature of PostgreSQL 8.2 can help
>> with this problem.
>
> I don't see how. The basic problem is that SQL is nondeterministic in
> general; you can't safely assume that evaluating the same sequence of
> SQL statements on all nodes will yield the same final database state.
Well, RETURNING means that there's some place which receives the
return set, which means that there is, in principle, a place where the
data would be capturable.
But it is important to point out that the "nondeterministic"
possibilities do not end with NOW() or CURRENT_TIMESTAMP; other
nondeterministic things that can cause trouble include:
a) A sequence value, which is set *somewhat* invisibly,
b) A query of the form
insert into some_table (select * from a_table);
where the SELECT subquery is not of the form:
SELECT [fields] FROM [a_table] WHERE [Fully Deterministic Criterion]
ORDER BY [some criterion suitable to be a primary key for the result set]
LIMIT [anything];
If you could capture the RETURNING data, and replicate that, well,
that at least provides a way to get around the nondeterminism problem.
That would work out well for both INSERT and DELETE. I'm not sure
it'll work as well for UPDATE; that doesn't return both old and new
column values :-(.
--
"cbbrowne","@","acm.org"
http://linuxdatabases.info/info/internet.html
"Problem solving under linux has never been the circus that it is
under AIX." -- Pete Ehlke in comp.unix.aix