Hello,

On Thu, 2007-06-14 at 16:14 -0700, Craig James wrote:
> Cluster
> Seems pretty good, but web site is not current,

http://www.pgcluster.org is a bit up2date, also
http://pgfoundry.org/projects/pgcluster is up2date (at least downloads
page )

Regards,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBGcq1Wpme12CBXnxERAgQCAJ9DCbyfP5j8n03DVR4e/SoZweFGcwCfXnmF
oO88ZH5qU/TopwtU8K5YA/w=
=ov3+
-----END PGP SIGNATURE-----

On Thu, 14 Jun 2007 17:38:01 -0700
Craig James <craig_james@emolecules.com> wrote:

> I would consider PGCluster, but it seems to be a patch to Postgres
> itself. I'm reluctant to introduce such a major piece of technology

Yes it is. For most of the time it is not very much behind actual
versions of postgresql. The project's biggest drawbacks, as I see:

- horrible documentation
- changing configuration without any warning/help to the "user"
(as far as there are only "rc"-s, I can't really blame the
developers for that... )

- there are only "rc" -s, no "stable" version available for current
postgresql releases.

I think this project needs someone speaking english very well, and
having the time and will to coordinate and document all the code that
is written. Otherwise the idea and the solution seems to be very good.
If someone - with big luck and lot of try-fail efforts - sets up a
working system, then it will be stable and working for long time.

> into our entire system, when only one tiny part of it needs the
> replication service.
>
> Thanks,
> Craig

Rgds,
Akos

--
Üdvözlettel,
Gábriel Ákos
-=E-Mail :akos.gabriel@i-logic.hu|Web: http://www.i-logic.hu =-
-=Tel/fax:+3612367353 |Mobil:+36209278894 =-

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Hi,

Joshua D. Drake wrote:
>> Slony-II
>> Seems brilliant, a solid theoretical foundation, at the forefront of
>> computer science. But can't find project status -- when will it be
>> available? Is it a pipe dream, or a nearly-ready reality?
>>
>
> Dead

Not quite... there's still Postgres-R, see www.postgres-r.org And I'm
continuously working on it, despite not having updated the website for
almost a year now...

I planned on releasing the next development snapshot together with 8.3,
as that seems to be delayed, that seems realistic ;-)

Regards

Markus


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Markus Schiltknecht wrote:
> Not quite... there's still Postgres-R, see www.postgres-r.org And I'm
> continuously working on it, despite not having updated the website for
> almost a year now...
>
> I planned on releasing the next development snapshot together with 8.3,
> as that seems to be delayed, that seems realistic ;-)

Is Postgres-R the same thing as Slony-II? There's a lot of info and news around about Slony-II, but your web page doesn't seem to mention it.

While researching replication solutions, I had a heck of a time sorting out the dead or outdated web pages (like the stuff on gborg) from the active projects.

Either way, it's great to know you're working on it.

Craig

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Thu, 2007-06-14 at 16:14 -0700, Craig James wrote:
> Looking for replication solutions, I find:
>
> Slony-I
> Seems good, single master only, master is a single point of failure,
> no good failover system for electing a new master or having a failed
> master rejoin the cluster. Slave databases are mostly for safety or
> for parallelizing queries for performance. Suffers from O(N^2)
> communications (N = cluster size).
>

There's MOVE SET which transfers the origin (master) from one node to
another without losing any committed transactions.

There's also FAILOVER, which can set a new origin even if the old origin
is completely gone, however you will lose the transactions that haven't
been replicated yet.

To have a new node join the cluster, you SUBSCRIBE SET, and you can MOVE
SET to it later if you want that to be the master.

Regards,
Jeff Davis



---------------------------(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

On Mon, Jun 18, 2007 at 08:54:46PM +0200, Markus Schiltknecht wrote:
> Postgres-R has been the name of the research project by Bettina Kemme et
> al. Slony-II was the name Neil and Gavin gave their attempt to continue
> that project.

This isn't quite true. Slony-II was originally conceived by Jan as
an attempt to implement some of the Postgres-R ideas. For our uses,
however, Postgres-R had built into it a rather knotty design problem:
under high-contention workloads, it will automatically increase the
number of ROLLBACKs users experience. Jan had some ideas on how to
solve this by moving around the GC events and doing slightly
different things with them.

To that end, Afilias sponsored a small workshop in Toronto during one
of the coldest weeks the city has ever seen. This should have been a
clue, perhaps. ;-) Anyway, the upshot of this was that two or three
different approaches were attempted in prototypes. AFAIK, Neil and
Gavin got the farthest, but just about everyone who was involved in
the original workshop all independently concluded that the approach
we were attempting to get to work was doomed -- it might go, but
the overhead was great enough that it wouldn't be any benefit.

Part of the problem, as near as I could tell, was that we had no
group communication protocol that would really work. Spread needed a
_lot_ of work (where "lot of work" may mean "rewrite"), and I just
didn't have the humans to put on that problem. Another part of the
problem was that, for high-contention workloads like the ones we
happened to be working on, an optimistic approach like Postgres-R is
probably always going to be a loser.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Hi,

Andrew Sullivan wrote:
> This isn't quite true. Slony-II was originally conceived by Jan as
> an attempt to implement some of the Postgres-R ideas.

Oh, right, thanks for that correction.

> Part of the problem, as near as I could tell, was that we had no
> group communication protocol that would really work. Spread needed a
> _lot_ of work (where "lot of work" may mean "rewrite"), and I just
> didn't have the humans to put on that problem. Another part of the
> problem was that, for high-contention workloads like the ones we
> happened to be working on, an optimistic approach like Postgres-R is
> probably always going to be a loser.

Hm.. for high-contention on single rows, sure, yes - you would mostly
get rollbacks for conflicting transactions. But the optimism there is
justified, as I think most real world transactions don't conflict (or
else you can work around such high single row contention).

You are right in that the serialization of the GCS can be bottleneck.
However, there's lots of research going on in that area and I'm
convinced that Postgres-R has it's value.

Regards

Markus


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly