>databases. I am trying to find out more information about how to do automatic
>replication with postgresql.
>
We did some research on this several months ago, and published the
results here
http://gborg.postgresql.org/genpage?replication_research
>
>
>
> My questions are :
>
>
>
>
>
>Unless 7.3 slips drastically from our current intended schedule
>(beta in late August), I think it's pretty safe to say there will
>be no replication in 7.3, beyond what's already available (rserv
>and so forth).
>
I can't speak for any of the other replication projects, but
pgreplication
I'm trying to compile an old version of Postgres and suddenly I've got
the folloging error message:
This looks to be the working model of postgres-r. Did you get it via CVS
or from
the down load area?
These questions should probably be asked on the pg-replication list
instead of hackes.
I'm now implementing 2PC replication and distributed transaction. My 2PC
needs some supports in startup packet to establish a replication session
or a recovery session.
BTW, my 2PC replication is working, and I'm implementing 2PC recovery now.
I would like to here more about your implementati
Lets say we have systems A, B and C. Each one has some
changes and sends a writeset to the group communication
system (GSC). The total order dictates WS(A), WS(B), and
WS(C) and the writes sets are recieved in that order at
each system. Now C gets WS(A) no conflict, gets WS(B) no
conflict, a
b) The Group Communication blob will consist of a number of processes which
need to talk to all of the others to interrogate them for changes which may
conflict with the current write that being handled and then issue the
transaction response. This is basically the two phase commit solution with
Next, pg-r was originally based on 6.4, so what was changed for
current pg versions when MV is used for CC? It seems that locking
tuples via LockTable at Phase 1 is not required anymore, right?
We haven't put those hooks in yet, so the current version is master/slave.
Upon receiving local
We have been researching replication for several months now, and
I have some opinions to share to the community for feedback,
discussion, and/or participation. Our goal is to get a replication
solution for PostgreSQL that will meet most needs of users
and applications alike (mission impossible the
> which I believe is what the rserv implementation in contrib currently
does
> ... no?
We tried rserv, PG Link (Joseph Conway), and PosrgreSQL Replicator. All
these projects are trigger based asynchronous replication. They all have
some advantages over the current functionality of Postgres-R
> Imho an implementation that opens a separate client connection to the
> replication target is only suited for async replication, and for that a
WAL
> based solution would probably impose less overhead.
Yes there is significant overhead with opening a connection to a
client, so Postgres-R c
We have been researching replication for several months now, and
I have some opinions to share to the community for feedback,
discussion, and/or participation. Our goal is to get a replication
solution for PostgreSQL that will meet most needs of users
and applications alike (mission impossible the
> > Here are some disadvantages to using a "trigger based" approach:
> >
> > 1) Triggers simply transfer individual data items when they
> > are modified, they do not keep track of transactions.
> I don't know about other *async* replication engines but Rserv
> keeps track of transactions (if I
> > - only full replication possible
> I do not understand that point, if it is trigger based, you
> have all the flexibility you need. (only some tables, only some rows,
> different rows to different targets ),
> (or do you mean not all targets, that could also be achieved with
triggers)
Sure. The mailing list is
http://www.greatbridge.org/mailman/listinfo/pgreplication-general
It's not only for Postgres-R, but any PostgreSQL
replication ideas, discussions, or projects.
Feel free to listen or contribute.
Darren
BTW: My apologies for the email issues. Should be fixed now.
Sean
Sean Chittenden wrote:
> Has anyone here thought about using the spread libraries for WAL
> replication amongst mutliple hosts? With this library I think it'd be
> possible to have a multi-master replication system..
Yes, there is some work being done to use Spread as the group
communi
Justin Clift wrote:
> If you finalise this into a decent procedure (and/or scripts), then
> would you mind contributing them? I can place them on the
> techdocs.postgresql.org website as a start.
>
Not at all, I plan to contribute any/all work I am
involved with. This would be part of valid
>
>
> Unfortunatly this seems to be asynchronous replication (you manually
> have to initiate the syncronization)...
>
> I'd like to have synchronous replication...
There is a synchronous replication project here...
http://www.greatbridge.org/project/pgreplication/projdisplay.php
We currentl
>
> Once we have schemas (7.3, I hope), I think a lot of installations will
> have only one production database. However, if we were going to do this
> what we'd probably do is allow the DBA to configure the postmaster to
> start N pre-forked backends per database, where N can depend on the
> d
>
> I've been looking for documents and other info on replication efforts
> in PostgreSQL. If anyone here can point me to places where I can
> find these, it would be really appreciated.
Here is some research work that was conducted a few months ago.
http://gborg.postgresql.org/genpage?rep
19 matches
Mail list logo
