I meant he is merging it into HEAD, not the 7.3 CVS. Sorry for the
confusion.
---
Thomas O'Connell wrote:
> So if this gets added to the 7.3 branch, will there be documentation
> accompanying it?
>
> -tfo
>
> In article
So if this gets added to the 7.3 branch, will there be documentation
accompanying it?
-tfo
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bruce Momjian) wrote:
> OK, I just talked to Patrick on the phone, and he says Neil Conway is
> working on merging the code into 7.3, and adding missing
Oops, sorry. Permissions fixed.
---
Janardhan wrote:
> The file "ftp://candle.pha.pa.us/pub/postgresql/PITR_20020822_02.gz";
> do not
> have read permissions to copy. please provide the read permissions to copy.
>
> Reg
The file "ftp://candle.pha.pa.us/pub/postgresql/PITR_20020822_02.gz"
do not
have read permissions to copy. please provide the read permissions to
copy.
Regards
jana
Patrick Macdonald wrote:
Bruce Momjian wrote:
I wanted to outline some of the big items we are loo
Patrick Macdonald wrote:
> > OK, I just talked to Patrick on the phone, and he says Neil Conway is
> > working on merging the code into 7.3, and adding missing pieces like
> > logging table creation. So, it seems PITR is moving forward.
>
> Well, sort of. I stated that Neil was already working o
Bruce Momjian wrote:
>
> Patrick Macdonald wrote:
> > Bruce Momjian wrote:
> > >
> > > I wanted to outline some of the big items we are looking at for 7.4:
> > >
> > > [snip]
> > >
> > > Point-In-Time Recovery (PITR)
> > >
> > > J. R. Nield did a PITR patch late in 7.3 development, and Pat
On Mon, 2002-12-16 at 13:38, Bruce Momjian wrote:
> OK, I just talked to Patrick on the phone, and he says Neil Conway is
> working on merging the code into 7.3, and adding missing pieces like
> logging table creation. So, it seems PITR is moving forward. Neil, can
> you comment on where you are
Patrick Macdonald wrote:
> Bruce Momjian wrote:
> >
> > I wanted to outline some of the big items we are looking at for 7.4:
> >
> > [snip]
> >
> > Point-In-Time Recovery (PITR)
> >
> > J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> > MacDonald from Red Hat i
Bruce Momjian wrote:
>
> I wanted to outline some of the big items we are looking at for 7.4:
>
> [snip]
>
> Point-In-Time Recovery (PITR)
>
> J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> MacDonald from Red Hat is working on merging it into CVS and
>
Shridhar Daithankar wrote:
> On Monday 16 December 2002 08:07 pm, you wrote:
> > On Mon, 2002-12-16 at 08:20, Shridhar Daithankar wrote:
> > > I don't know about WAL numbering but AFAIU, it increments and old files
> > > are removed once there are enough WAL files as specified in
> > > posgresql.co
On Monday 16 December 2002 08:07 pm, you wrote:
> On Mon, 2002-12-16 at 08:20, Shridhar Daithankar wrote:
> > I don't know about WAL numbering but AFAIU, it increments and old files
> > are removed once there are enough WAL files as specified in
> > posgresql.conf. IIRC there are some perl based re
On Mon, 2002-12-16 at 08:20, Shridhar Daithankar wrote:
> On Monday 16 December 2002 07:43 pm, you wrote:
> > Consider that on the slave which is now the active server (master dead),
> > it's possible that the slave's PITR's will be recycled before the master
> > can come back up. As such, unless
On Monday 16 December 2002 07:43 pm, you wrote:
> Consider that on the slave which is now the active server (master dead),
> it's possible that the slave's PITR's will be recycled before the master
> can come back up. As such, unless there is a, an archival process for
> PITR or b, a method of str
I must of miscommunicated here as you're describing PITR replication.
I'm asking about a master failing and the slaving picking up. Now, some
n-time later, how do you recover your master system to be back in sync
with the slave. Obviously, I'm assuming some level of manual recovery.
I'm wonderi
On Monday 16 December 2002 07:26 pm, you wrote:
> I'm curious, what would be the recovery strategy for PITR master-slave
> replication should the master fail (assuming hot fail over/backup)? A
> simple dump/restore? Are there/is there any facilities in PorstgreSQL
> for PITR archival which preven
On Fri, 2002-12-13 at 04:53, Hannu Krosing wrote:
> On Fri, 2002-12-13 at 06:22, Bruce Momjian wrote:
> > I wanted to outline some of the big items we are looking at for 7.4:
> > Point-In-Time Recovery (PITR)
> >
> > J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> > Mac
Darren Johnson wrote:
> The group communication system doesn't just run on one system. For
> postgres-r using spread
The reason why group communication software is used is simply because
this software is designed with two goals in mind:
1) optimize bandwidth usage
2) make many-to-many communic
PROTECTED]>; "Bruce Momjian"
<[EMAIL PROTECTED]>; "Jan Wieck" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; "PostgreSQL-development"
<[EMAIL PROTECTED]>
Sent: Sunday, December 15, 2002 9:17 PM
Subject: Re: [mail] Re: [HACKERS] Big 7.4 item
>; "Bruce Momjian"
<[EMAIL PROTECTED]>; "Jan Wieck" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; "PostgreSQL-development"
<[EMAIL PROTECTED]>
Sent: Sunday, December 15, 2002 5:00 PM
Subject: Re: [mail] Re: [HACKERS] Big 7.4 items - Replication
ot;Darren Johnson"
<[EMAIL PROTECTED]>
Cc: "Bruce Momjian" <[EMAIL PROTECTED]>; "Jan Wieck"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
"PostgreSQL-development" <[EMAIL PROTECTED]>
Sent: Sunday, December 15, 2002 2:29 PM
Subject: Re:
mjian" <[EMAIL PROTECTED]>; "Jan Wieck"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> "PostgreSQL-development" <[EMAIL PROTECTED]>
> Sent: Saturday, December 14, 2002 6:48 PM
> Subject: Re: [mail] Re: [HACKERS] Big 7.4 items - Replic
: "Darren Johnson" <[EMAIL PROTECTED]>
To: "Al Sutton" <[EMAIL PROTECTED]>
Cc: "Bruce Momjian" <[EMAIL PROTECTED]>; "Jan Wieck"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
"PostgreSQL-development" <[EMAIL PROTECTED]&g
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
[EMAIL PROTECTED]>
To: "Al Sutton" <[EMAIL PROTECTED]>
Cc: "Darren Johnson" <[EMAIL PROTECTED]>; "Jan Wieck"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
"PostgreSQL-development" <[EMAIL PROTECTED]>
Sent: Saturday, December 14,
--En cette belle journée de samedi 14 décembre 2002 11:59 -0500,
-- Bruce Momjian écrivait avec ses petits doigts :
>
> This sounds like two-phase commit. While it will work, it is probably
> slower than Postgres-R's method.
What exactly is Postgres-R's method ?
--
Mathieu Arnold
---
ich
> should be the case for a well designed system).
>
> Comments?
>
> Al.
>
>
>
>
>
>
> - Original Message -
> From: "Darren Johnson" <[EMAIL PROTECTED]>
> To: "Jan Wieck" <[EMAIL PROTECTED]>
> Cc:
- Original Message -
From: "Darren Johnson" <[EMAIL PROTECTED]>
To: "Jan Wieck" <[EMAIL PROTECTED]>
Cc: "Bruce Momjian" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; "PostgreSQL-development"
<[EMAIL PROTECTED]>
Sent:
> > I think in either way, it's clear that they need to be in the main CVS, in
> > order for it to get up to speed.
>
> Why's that?
Because until replication is in CVS, it won't be used, tested and improved
and developed as fast...
Chris
---(end of broadcast)---
Dear all,
Why not use libgda, Gnome-DB database provider, to be able to attach foreign
tables inside PostgreSQL. Would it be hard to achieve?
Many users are looking for such a solution to be able to query/update tables
outside PostgreSQL in Oracle, MS SQL Server, IBM DB2 or even MySQL databases
On 14 Dec 2002 at 18:02, Justin Clift wrote:
> For PITR-log-based-replication, how much data would be required to be pushed out to
>each slave system in order to bring
> it up to date?
>
> I'm having visions of a 16MB WAL file being pushed out to slave systems in order to
>update them with a fe
Bruce Momjian wrote:
Joe Conway wrote:
Point-In-Time Recovery (PITR)
J. R. Nield did a PITR patch late in 7.3 development, and Patrick
MacDonald from Red Hat is working on merging it into CVS and
adding any missing pieces. Patrick, do you have an ETA on that?
As Hannu asked (and related
[EMAIL PROTECTED] wrote:
It is asynchronous without the need of 2 phase commit. It is group
communication based and requires the group communication system to
guarantee total order. The tricky part is, that the local transaction
must be on hold until the own commit message comes back without a pri
On Friday 13 December 2002 11:01 pm, you wrote:
> Good. This is the discussion we need. Let me quote the TODO list
> replication section first:
>
> * Add replication of distributed databases [replication]
> o automatic failover
Very good. We need that for HA.
> o load balanc
On Fri, 2002-12-13 at 20:20, Christopher Kings-Lynne wrote:
> > This is a good point. I don't want to push Postgres-R as our solution.
> > Rather, I have looked at both and like Postgres-R, but others need to
> > look at both and decide so we are all in agreement when we move forward.
>
> I think
Bruce Momjian wrote:
>
> Joe Conway wrote:
> > Bruce Momjian wrote:
> > > Win32 Port:
> > >
> > > Katie Ward and Jan are working on contributing their Win32
> > > port for 7.4. They plan to have a patch available by the end of
> > > December.
> >
> > I have .Net Studio available to me
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
> This is a good point. I don't want to push Postgres-R as our solution.
> Rather, I have looked at both and like Postgres-R, but others need to
> look at both and decide so we are all in agreement when we move forward.
I think in either way, it's clear that they need to be in the main CVS, in
or
Neil Conway wrote:
> On Fri, 2002-12-13 at 13:36, Jan Wieck wrote:
> > But you cannot use the result of such a SELECT to update anything. So
> > you can only phase out complete read only transaction to the slaves.
> > Requires support from the application since the load balancing system
> > cannot
On Fri, 2002-12-13 at 13:36, Jan Wieck wrote:
> But you cannot use the result of such a SELECT to update anything. So
> you can only phase out complete read only transaction to the slaves.
> Requires support from the application since the load balancing system
> cannot know automatically what will
[EMAIL PROTECTED] wrote:
>
> > It is asynchronous without the need of 2 phase commit. It is group
> > communication based and requires the group communication system to
> > guarantee total order. The tricky part is, that the local transaction
> > must be on hold until the own commit message comes
[EMAIL PROTECTED] wrote:
> >
> >
> > Darren, can you clarify this? Why does it send that message? How does
> > it allow commits not to wait for ordered writesets?
> >
>
> There are two channels. One for total order writesets
> (changes to the DB). The other is simple order for
> aborts, c
[EMAIL PROTECTED] wrote:
>
> >
> >
> > Darren, can you clarify this? Why does it send that message? How does
> > it allow commits not to wait for ordered writesets?
> >
>
> There are two channels. One for total order writesets
> (changes to the DB). The other is simple order for
> aborts, com
>
>
> Darren, can you clarify this? Why does it send that message? How does
> it allow commits not to wait for ordered writesets?
>
There are two channels. One for total order writesets
(changes to the DB). The other is simple order for
aborts, commits, joins (systems joining the replica)
[EMAIL PROTECTED] wrote:
> > It is asynchronous without the need of 2 phase commit. It is group
> > communication based and requires the group communication system to
> > guarantee total order. The tricky part is, that the local transaction
> > must be on hold until the own commit message comes bac
> > It is asynchronous without the need of 2 phase commit. It is group
>
> Well, Darren's PDF at:
>
>
>ftp://gborg.postgresql.org/pub/pgreplication/stable/PostgreSQLReplication.pdf.gz
>
> calls Postgres-R "Type: Embedded, Peer-to-Peer, Sync". I don't know
> enough about replication so I
> It is asynchronous without the need of 2 phase commit. It is group
> communication based and requires the group communication system to
> guarantee total order. The tricky part is, that the local transaction
> must be on hold until the own commit message comes back without a prior
No, It holds u
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > OK, the first thing is that there isn't any one replication solution
> > that will behave optimally in all situations.
>
> Right
>
> > Now, let me describe Postgres-R and then the other replication
> > solutions. Postgres-R is multi-master, meaning
[EMAIL PROTECTED] wrote:
> > > Note that while Spread is open source in the sense that "the source is
> > > available", it's license is significantly more restrictive than
> > > PostgreSQL's:
> > >
> > > http://www.spread.org/license/
> > >
> >
> > Interesting. It looks like a modified vers
> > Note that while Spread is open source in the sense that "the source is
> > available", it's license is significantly more restrictive than
> > PostgreSQL's:
> >
> > http://www.spread.org/license/
> >
>
> Interesting. It looks like a modified version of the old BSD license
> where you ar
Bruce Momjian wrote:
> OK, the first thing is that there isn't any one replication solution
> that will behave optimally in all situations.
Right
> Now, let me describe Postgres-R and then the other replication
> solutions. Postgres-R is multi-master, meaning you can send SELECT and
> UPDATE/DE
I wrote:
>
> I guess I'm basically asking:
>
> 1) Is it necessary to *choose* between support for 2PC and Spread (Postgres-R) or
>can't we have both? Spread for Replication, 2PC for non-replicating distributed TX?
>
> 2) Do major SQL DBMS vendors which support distributed options expose a calla
Neil Conway wrote:
> On Fri, 2002-12-13 at 13:20, Bruce Momjian wrote:
> > Let me address the Spread issue and two-phase commit. (Spread is an
> > open source piece of software used by Postgres-R.)
>
> Note that while Spread is open source in the sense that "the source is
> available", it's licen
On Fri, 2002-12-13 at 13:20, Bruce Momjian wrote:
> Let me address the Spread issue and two-phase commit. (Spread is an
> open source piece of software used by Postgres-R.)
Note that while Spread is open source in the sense that "the source is
available", it's license is significantly more restri
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> Mike Mascari wrote:
> > Okay. But please keep in mind that a 2-phase commit implementation
> > is used for more than just replication.
>
> This is a good point. I don't want to push Postgres-R as our solution.
> Rather,
Mike Mascari wrote:
> Okay. But please keep in mind that a 2-phase commit implementation
> is used for more than just replication. Any distributed TX will
> require a 2PC protocol. As an example, for the DBLINK implementation
> to ultimately be transaction safe (at least amongst multiple
> PostgreS
Joe Conway wrote:
> Bruce Momjian wrote:
> > Win32 Port:
> >
> > Katie Ward and Jan are working on contributing their Win32
> > port for 7.4. They plan to have a patch available by the end of
> > December.
>
> I have .Net Studio available to me, so if you need help in merging or test
On Friday 13 December 2002 17:51, Bruce Momjian wrote:
> Shridhar Daithankar wrote:
> > And where are nested transactions?
>
> I didn't mention nested transactions because it didn't seem to be a
> _big_ item like the others.
This is big item
regards
Haris Peco
---(end of
Okay. But please keep in mind that a 2-phase commit implementation is used for more
than just replication. Any distributed TX will require a 2PC protocol. As an example,
for the DBLINK implementation to ultimately be transaction safe (at least amongst
multiple PostgreSQL installations), the play
[EMAIL PROTECTED] wrote:
> >
> > How hard would it be to extend PITR for master-slave (hot backup)
> > repliaction, which should then amount to continuously shipping logs to
> > slave and doing nonstop PITR there :)
>
> I have not looked at the PITR patch yet, but it might be possible
> to use the
Mike Mascari wrote:
> What about distributed TX support:
>
>
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=20021106111554.69ae1dcd.pgsql%40snaga.org&rnum=2&prev=/groups%3Fq%3DNAGAYASU%2BSatoshi%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den
OK, yes, that is Satoshi's 2-phase commit i
Hannu Krosing wrote:
> On Fri, 2002-12-13 at 06:22, Bruce Momjian wrote:
> > I wanted to outline some of the big items we are looking at for 7.4:
> > Point-In-Time Recovery (PITR)
> >
> > J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> > MacDonald from Red Hat is workin
Shridhar Daithankar wrote:
> 1) What kind of replication are we looking at? log file
> replay/synchronous etc. If it is real time, like usogres( I
> hope I am in line with things here), that would be real good.
> Choice is always good.
Good. This is the discussion we need. Let me quote the TODO
Shridhar Daithankar wrote:
> And where are nested transactions?
I didn't mention nested transactions because it didn't seem to be a
_big_ item like the others.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your li
Bruce Momjian wrote:
Win32 Port:
Katie Ward and Jan are working on contributing their Win32
port for 7.4. They plan to have a patch available by the end of
December.
I have .Net Studio available to me, so if you need help in merging or testing
or whatever, let me know.
Point-In-Time Recov
>
> How hard would it be to extend PITR for master-slave (hot backup)
> repliaction, which should then amount to continuously shipping logs to
> slave and doing nonstop PITR there :)
I have not looked at the PITR patch yet, but it might be
possible to use the same PITR format to queue/log writese
Bruce Momjian wrote:
I wanted to outline some of the big items we are looking at for 7.4:
Win32 Port:
Katie Ward and Jan are working on contributing their Win32
port for 7.4. They plan to have a patch available by the end of
December.
Point-In-Time Recovery (PITR)
J. R. Nield did a PITR p
On Fri, 2002-12-13 at 06:22, Bruce Momjian wrote:
> I wanted to outline some of the big items we are looking at for 7.4:
> Point-In-Time Recovery (PITR)
>
> J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> MacDonald from Red Hat is working on merging it into CVS and
On 13 Dec 2002 at 1:22, Bruce Momjian wrote:
> Replication
>
> I have talked to Darren Johnson and I believe 7.4 is the time to
> merge the Postgres-R source tree into our main CVS. Most of the
> replication code will be in its own directory, with only minor
> changes to o
I wanted to outline some of the big items we are looking at for 7.4:
Win32 Port:
Katie Ward and Jan are working on contributing their Win32
port for 7.4. They plan to have a patch available by the end of
December.
Point-In-Time Recovery (PITR)
J. R. Nield did a
69 matches
Mail list logo
