Of course I have no time to work on it : (, but in my opinion XA interface
and support for the JDBC driver is absolutely necessary. I think that 2pc
will generally be used more for supporting 2pc transactions between the DB
and JMS than it would be for 2pc across 2 db's.
Glad to see some
On Fri, 10 Oct 2003, Heikki Linnakangas wrote:
On Thu, 9 Oct 2003, Bruce Momjian wrote:
Agreed. Let's get it into 7.5 and see it in action. If we need to
adjust it, we can, but right now, we need something for distributed
transactions, and this seems like the logical direction.
I've
Satoshi, can you get this ready for inclusion in 7.5? We need a formal
proposal of how it will work from the user's perspective (new
commands?), and how it will internally work. It seem Heikki Linnakangas
has also started working on this and perhaps he can help.
Ideally, we should have this
Bruce,
Ok, I will write my proposal.
BTW, my 2PC work is now suspended because of my master thesis.
My master thesis will (must) be finished in next few months.
To finish 2PC work, I feel 2 or 3 months are needed after that.
Bruce Momjian wrote:
Satoshi, can you get this ready for inclusion
Satoshi Nagayasu wrote:
Bruce,
Ok, I will write my proposal.
BTW, my 2PC work is now suspended because of my master thesis.
My master thesis will (must) be finished in next few months.
To finish 2PC work, I feel 2 or 3 months are needed after that.
Oh, OK, that is helpful. Perhaps
I'm tired of this kind of 2PC is too slow arguments. I think
Satoshi, the only guy who made a trial implementation of 2PC for
PostgreSQL, has already showed that 2PC is not that slow.
Where does Satoshi's implementation sit right now? Will it patch to v7.4?
Can it provide us with a base to work
On Thu, 9 Oct 2003, Bruce Momjian wrote:
Agreed. Let's get it into 7.5 and see it in action. If we need to
adjust it, we can, but right now, we need something for distributed
transactions, and this seems like the logical direction.
I've started working on two-phase commits last week, and
Why would you spent time on implementing a mechanism whose ultimate
benefit is supposed to be increasing reliability and performance, when you
already realize that it will have to lock up at the slightest sight of
trouble? There are better mechanisms out there that you can use instead.
If you
-Original Message-
From: Jeroen T. Vermeulen [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 11, 2003 5:36 AM
To: Dann Corbit
Cc: Christopher Browne; [EMAIL PROTECTED]
Subject: Re: [HACKERS] 2-phase commit
On Fri, Oct 10, 2003 at 09:37:53PM -0700, Dann Corbit wrote:
Why
I think another way it could be handled is with nested transactions.
Just have the promise phase be an inner transaction commit but have an
outer transaction bracket that one for the actual commit.
Not really. In the event of a crash, most 2PC systems will expect the
participant to come back
On Monday 13 October 2003 20:11, Rod Taylor wrote:
I think another way it could be handled is with nested transactions.
Just have the promise phase be an inner transaction commit but have an
outer transaction bracket that one for the actual commit.
Not really. In the event of a crash, most
Bruce Momjian wrote:
Tatsuo Ishii wrote:
Yes. I don't think that 2PC is a solution for robustness in face of
network failure. It's too slow, to begin with. Some sort of
multi-master system is very desirable for network failures, c., but
I don't think anybody does active/hot standby with
On Fri, Oct 10, 2003 at 09:37:53PM -0700, Dann Corbit wrote:
Why not apply the effort to something already done and compatibly
licensed?
This:
http://dog.intalio.com/ots.html
Appears to be a Berkeley style licensed:
http://dog.intalio.com/license.html
Transaction monitor.
I'd say
I was wondering whether we need to keep WAL online for 2PC,
or whether only something like clog is sufficient.
What if:
1. phase 1 commit must pass the slave xid that will be used for 2nd phase
(it needs to return some sort of identification anyway)
2. the coordinator
On Fri, Oct 10, 2003 at 09:46:35AM +0900, Tatsuo Ishii wrote:
Satoshi, the only guy who made a trial implementation of 2PC for
PostgreSQL, has already showed that 2PC is not that slow.
If someone has a fast implementation, so much the better. I'm not
opposed to fast implementations!
A
--
On Thu, Oct 09, 2003 at 11:53:46PM -0400, Christopher Browne wrote:
If 2PC gets implemented, that simply means that there will be another
module that some will be interested in, and which many people won't
bother using. Which shouldn't seem to be a particularly big deal.
I think the reason
Andrew Sullivan [EMAIL PROTECTED] wrote:
On Fri, Oct 10, 2003 at 09:46:35AM +0900, Tatsuo Ishii wrote:
Satoshi, the only guy who made a trial implementation of 2PC for
PostgreSQL, has already showed that 2PC is not that slow.
If someone has a fast implementation, so much the better. I'm
Martha Stewart called it a Good Thing [EMAIL PROTECTED] (Dann Corbit)wrote:
I can't see a grave overhead from this comparison.
2PC is absolutely essential when you have to have both parts of the
transaction complete for a logical unit of work. For a project that
needs it, if you don't have
Why not apply the effort to something already done and compatibly
licensed?
This:
http://dog.intalio.com/ots.html
Appears to be a Berkeley style licensed:
http://dog.intalio.com/license.html
Transaction monitor.
Overview
The OpenORB Transaction Service is a very scalable transaction monitor
Here is a sourceforge version of the same thing
http://openorb.sourceforge.net/
-Original Message-
From: Dann Corbit
Sent: Friday, October 10, 2003 9:38 PM
To: Christopher Browne; [EMAIL PROTECTED]
Subject: Re: [HACKERS] 2-phase commit
Why not apply the effort to something
On Wed, Oct 08, 2003 at 05:43:49PM -0400, Bruce Momjian wrote:
OK, I think we came to the conclusion that we want 2-phase commit, but
want some way to mark a server as offline/read-only, or notify an
That sounds to me like the concusion, to the extent there was one,
yes. I'd still like to
Andrew Sullivan writes:
Does the proposal of allowing dbas to run that risk, provided there's a
mechanism to tell them about it, satisfy the objection (assuming, of
course, 2PC can be turned off)?
Why would you spent time on implementing a mechanism whose ultimate
benefit is supposed to be
Peter Eisentraut wrote:
Andrew Sullivan writes:
Does the proposal of allowing dbas to run that risk, provided there's a
mechanism to tell them about it, satisfy the objection (assuming, of
course, 2PC can be turned off)?
Why would you spent time on implementing a mechanism whose
On Thu, Oct 09, 2003 at 04:22:13PM +0200, Peter Eisentraut wrote:
Why would you spent time on implementing a mechanism whose ultimate
benefit is supposed to be increasing reliability and performance, when you
already realize that it will have to lock up at the slightest sight of
trouble?
Bruce Momjian writes:
If you want cross-server transactions, what other methods are there that
are more reliable?
3-phase commit
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Why would you spent time on implementing a mechanism whose ultimate
benefit is supposed to be increasing reliability and performance, when you
already realize that it will have to lock up at the slightest sight of
trouble? There are better mechanisms out there that you can use instead.
Bruce Momjian wrote:
Peter Eisentraut wrote:
Andrew Sullivan writes:
Does the proposal of allowing dbas to run that risk, provided there's a
mechanism to tell them about it, satisfy the objection (assuming, of
course, 2PC can be turned off)?
Why would you spent time on implementing a
Peter Eisentraut wrote:
Bruce Momjian writes:
If you want cross-server transactions, what other methods are there that
are more reliable?
3-phase commit
OK, how is that going to make thing safer, or does it just shrink the
failure window smaller?
--
Bruce Momjian
On Thu, 2003-10-09 at 11:14, Peter Eisentraut wrote:
Bruce Momjian writes:
If you want cross-server transactions, what other methods are there that
are more reliable?
3-phase commit
How about a real world example of a transaction manager that has
actually implemented 3PC?
But yes, the
On Thu, Oct 09, 2003 at 11:22:05AM -0400, Mike Mascari wrote:
The implementation choosen depends upon the answer, does it not? Is
there an implementation (e.g. 3PC) that can simulate 2PC behavior for
interoperability purposes and satisfy both requirements?
I don't know. What I know is that
On Thu, 2003-10-09 at 12:07, Andrew Sullivan wrote:
On Thu, Oct 09, 2003 at 11:22:05AM -0400, Mike Mascari wrote:
The implementation choosen depends upon the answer, does it not? Is
there an implementation (e.g. 3PC) that can simulate 2PC behavior for
interoperability purposes and satisfy
On Thu, Oct 09, 2003 at 02:17:28PM -0400, Robert Treat wrote:
Can you elaborate on your purposes? Do they fall into the
XA-compatibility bit or the Robustness in the face of network
failure?
Yes. I don't think that 2PC is a solution for robustness in face of
network failure. It's too
Yes. I don't think that 2PC is a solution for robustness in face of
network failure. It's too slow, to begin with. Some sort of
multi-master system is very desirable for network failures, c., but
I don't think anybody does active/hot standby with 2PC any more; the
performance is too bad.
Tatsuo Ishii wrote:
Yes. I don't think that 2PC is a solution for robustness in face of
network failure. It's too slow, to begin with. Some sort of
multi-master system is very desirable for network failures, c., but
I don't think anybody does active/hot standby with 2PC any more; the
On Fri, 10 Oct 2003, Tatsuo Ishii wrote:
Yes. I don't think that 2PC is a solution for robustness in face of
network failure. It's too slow, to begin with. Some sort of
multi-master system is very desirable for network failures, c., but
I don't think anybody does active/hot standby
The world rejoiced as [EMAIL PROTECTED] (Tatsuo Ishii) wrote:
I'm tired of this kind of 2PC is too slow arguments. I think
Satoshi, the only guy who made a trial implementation of 2PC for
PostgreSQL, has already showed that 2PC is not that slow.
I'm tired of it for a different reason, namely
Andrew Sullivan wrote:
On Sat, Sep 27, 2003 at 09:13:27AM -0300, Marc G. Fournier wrote:
I think it was Andrew that suggested it ... when the slave timesout, it
should trigger a READ ONLY mode on the slave, so that when/if the master
tries to start to talk to it, it can't ...
As for
Marc G. Fournier wrote:
On Sat, 27 Sep 2003, Bruce Momjian wrote:
I have been thinking it might be time to start allowing external
programs to be called when certain events occur that require
administrative attention --- this would be a good case for that.
Administrators could configure shell
I seem to have misunderstood the problem completely.
(BI apologize to you all(especially Tom) for disturbing
(Bthis thread.
(B
(BI wonder if there might be such a nice solution when
(Bsome of the systems or communications are dead.
(BAnd as many people already mentioned, there's not so
The simplest senario(though there could be varations) is
[At participant(master)'s side]
Because the commit operations is done, does nothing.
[At coordinator(slave)' side]
1) After a while
2) re-establish the communication path between the
On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
The simplest senario(though there could be varations) is
[At participant(master)'s side]
Because the commit operations is done, does nothing.
Marc G. Fournier wrote:
Master Slave
-- -
commit ready--
--OK
commit done-XX
is the commit done message needed ?
Of course ... how else will the Slave commit? From my understanding, the
concept is
Tom Lane wrote:
[At participant(master)'s side]
Because the commit operations is done, does nothing.
[At coordinator(slave)' side]
1) After a while
2) re-establish the communication path between the
partcipant(master)'s TM.
3) resend the commit requeset to the
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
... You can make this work, but the resource costs
are steep.
So, after 'n' seconds of waiting, we abandon the slave and the slave
abandons the master.
[itch...] But you surely cannot guarantee that the slave and the
On Mon, 29 Sep 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
Master Slave
-- -
commit ready--
--OK
commit done-XX
is the commit done message needed ?
Of course ... how else will the
I don't think there is any way to handle cases where the master or slave
just disappears. The other machine isn't under the server's control, so
it has no way of it knowing. I think we have to allow the administrator
to set a timeout, or ask to wait indefinately, and allow them to call an
Master Slave
-- -
commit ready--
--OK
commit done-XX
is the commit done message needed ?
Of course ... how else will the Slave commit? From my
understanding, the
concept is that the
Marc G. Fournier wrote:
is the commit done message needed ?
Of course ... how else will the Slave commit? From my understanding, the
concept is that the master sends a commit ready to the slave, but the OK
back is that OK, I'm ready to commit whenever you are, at which point
Hiroshi Inoue [EMAIL PROTECTED] writes:
But is it 2-phase commit protocol in the first place ?
That is, in your exmaple below
Example:
Master Slave
-- -
commit ready--
--OK
commit done-XX
is the commit
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
I thought the slave could reject if someone local already had the row
locked.
No, not at all. The slave would need to reject phase 1 commit ready
for this.
Andreas
On Sat, Sep 27, 2003 at 09:13:27AM -0300, Marc G. Fournier wrote:
I think it was Andrew that suggested it ... when the slave timesout, it
should trigger a READ ONLY mode on the slave, so that when/if the master
tries to start to talk to it, it can't ...
As for the master itself, it should
Zeugswetter Andreas SB SD wrote:
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
I thought the slave could reject if someone local already had the row
locked.
No, not at all. The slave would need to reject phase 1 commit ready
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
I thought the slave could reject if someone local already had the row
locked.
All normal reasons for
On Sun, Sep 28, 2003 at 11:58:24AM -0700, Kevin Brown wrote:
But the postmaster doesn't connect to any database, and in a serious
failure, might not be able to start one.
Ah, true. But I figured that in the context of 2PC and replication that
most of the associated failures were likely to
Andrew Sullivan wrote:
On Sat, Sep 27, 2003 at 09:13:27AM -0300, Marc G. Fournier wrote:
I think it was Andrew that suggested it ... when the slave timesout, it
should trigger a READ ONLY mode on the slave, so that when/if the master
tries to start to talk to it, it can't ...
As for
On Mon, Sep 29, 2003 at 11:14:30AM -0300, Marc G. Fournier wrote:
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
In every circumstance where a stand-alone machine would have it.
Machine A may not yet know about conflicting transactions on
Bruce Momjian [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
I thought the slave could reject if someone local already had the row
locked.
All normal reasons for transaction failure are
On Sat, Sep 27, 2003 at 08:36:36AM +, Jeff wrote:
What do commercial databases do about 2PC or other multi-master solutions?
You've done a good job of convincing me that it's unreliable no matter what
(through your posts on this topic over a long time). However, I would think
that
On Fri, Sep 26, 2003 at 05:15:37PM -0400, Rod Taylor wrote:
The first problem is the restart/rejoin problem. When a 2PC member
goes away, it is supposed to come back with all its former locks and
everything in place, so that it can know what to do. This is also
extremely tricky, but I
It seems that one way out is just to fall back to read only as soon
as a single failure happens. That's the least graceful but maybe
safest approach to failure, analogous to what fsck does to your root
filesystem at boot time. Of course, since there's no read only
mode at the moment,
Tom Lane writes:
No. The real problem with 2PC in my mind is that its failure modes
occur *after* you have promised commit to one or more parties. In
multi-master, if you fail you know it before you have told the client
his data is committed.
I have a book here which claims that the
No, I'm not. One needs to decide how to handle the situation where a
slave database in a 2PC transaction goes away and comes back, for
whatever reasons that may happen. Since the idea here is to come up
with ways of handling the failure of 2PC in some cases, we need
something which notices
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2003 7:10 AM
To: Marc G. Fournier
Cc: Hiroshi Inoue; Tom Lane; 'Zeugswetter Andreas SB SD';
'Andrew Sullivan'; [EMAIL PROTECTED]
Subject: Re: [HACKERS] 2-phase commit
Marc G. Fournier
Peter Eisentraut wrote:
Tom Lane writes:
No. The real problem with 2PC in my mind is that its failure modes
occur *after* you have promised commit to one or more parties. In
multi-master, if you fail you know it before you have told the client
his data is committed.
I have a book here
Manfred Spraul writes:
Ok. Lets assume one coordinator, two partitipants.
Global commit send to both by coordinator. One replies with ok, the
other one remains silent.
What should the coordinator do? It can't fail the transaction - the
first partitipant has commited its part. It can't
On Mon, 2003-09-29 at 15:55, Peter Eisentraut wrote:
Manfred Spraul writes:
Ok. Lets assume one coordinator, two partitipants.
Global commit send to both by coordinator. One replies with ok, the
other one remains silent.
What should the coordinator do? It can't fail the transaction -
On Mon, Sep 29, 2003 at 12:59:55PM -0400, Bruce Momjian wrote:
working on. I think we have to get beyond the idea that this can be made
failure-proof, and just outline the behaviors for failure, and it has to
be configurable by the administrator.
Exactly. There are plenty of cases where
Commercial systems use:
Mainframe:
CICS
UNIX:
Tuxedo
Encina
Win32:
MTS
DEC/COMPAQ/HP:
ACMS
Probably lots of others that I have never heard about.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Mon, Sep 29, 2003 at 12:48:30PM -0400, Andrew Sullivan wrote:
In every circumstance where a stand-alone machine would have it.
Oops. Wrong stage. Never mind.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario
[EMAIL PROTECTED] (Dann Corbit) writes:
Tuxedo
Note that this is probably the only one of the lot that is _really_
worth looking at in a serious way, as the XA standard was essentially
based on Tuxedo. (Irrelevant Aside: BEA had releases of CICS running
on both Unix and Windows NT, so it isn't
A really nice overview of how various transaction managers are modeled:
http://www.ti5.tu-harburg.de/Lecture/99ws/TP/06-OverviewOfTPSystemsAndPr
oducts/sld001.htm
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Bruce Momjian wrote:
Kevin Brown wrote:
Actually, all that's really necessary is the ability to call a stored
procedure when some event occurs. The stored procedure can take it from
there, and since it can be written in C it can do anything the postgres
user can do (for good or for ill,
Actually, all that's really necessary is the ability to call a stored
procedure when some event occurs. The stored procedure can take it from
there, and since it can be written in C it can do anything the postgres
user can do (for good or for ill, of course).
But the postmaster doesn't
Hiroshi Inoue wrote:
(B
(B -Original Message-
(B From: Tom Lane
(B
(B Bruce Momjian [EMAIL PROTECTED] writes:
(B Tom Lane wrote:
(B You're not considering the possibility of a transient communication
(B failure.
(B
(B Can't the master re-send the request after a
On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
The simplest senario(though there could be varations) is
[At participant(master)'s side]
Because the commit operations is done, does nothing.
[At coordinator(slave)' side]
1) After a while
2) re-establish the communication path between
Hiroshi Inoue [EMAIL PROTECTED] writes:
The simplest senario(though there could be varations) is
[At participant(master)'s side]
Because the commit operations is done, does nothing.
[At coordinator(slave)' side]
1) After a while
2) re-establish the communication path between the
Tom Lane wrote:
(B
(B Hiroshi Inoue [EMAIL PROTECTED] writes:
(B The simplest senario(though there could be varations) is
(B
(B [At participant(master)'s side]
(BBecause the commit operations is done, does nothing.
(B
(B [At coordinator(slave)' side]
(B 1) After a while
(B
(B
(BHiroshi Inoue wrote:
(B
(B Tom Lane wrote:
(B
(B Hiroshi Inoue [EMAIL PROTECTED] writes:
(B The simplest senario(though there could be varations) is
(B
(B [At participant(master)'s side]
(B Because the commit operations is done, does nothing.
(B
(B [At
Tom Lane wrote:
(B
(B Hiroshi Inoue [EMAIL PROTECTED] writes:
(B The simplest senario(though there could be varations) is
(B
(B [At participant(master)'s side]
(BBecause the commit operations is done, does nothing.
(B
(B [At coordinator(slave)' side]
(B 1) After a while
(B
On Saturday 27 September 2003 06:59, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
... You can make this work, but the resource costs
are steep.
So, after 'n' seconds of waiting, we abandon the slave and the slave
abandons the master.
[itch...] But you surely
On Sat, 27 Sep 2003, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
... You can make this work, but the resource costs
are steep.
So, after 'n' seconds of waiting, we abandon the slave and the slave
abandons the master.
[itch...] But you surely cannot guarantee
Richard Huxton wrote:
[itch...] But you surely cannot guarantee that the slave and the master
time out at exactly the same femtosecond. What happens when the comm
link comes back online just when one has timed out and the other not?
(Hint: in either order, it ain't good. Double plus
On Saturday 27 September 2003 20:17, Bruce Momjian wrote:
Richard Huxton wrote:
I have been thinking it might be time to start allowing external
programs to be called when certain events occur that require
administrative attention --- this would be a good case for that.
Administrators could
On Saturday 27 September 2003 15:47, Bruce Momjian wrote:
Richard Huxton wrote:
[snip]
I might be (well, am actually) a bit out of my depth here, but surely
what happens is if you have machines A,B,C and *any* of them thinks
machine C has a problem then it does. If C can still communicate
On Sat, 27 Sep 2003, Bruce Momjian wrote:
I have been thinking it might be time to start allowing external
programs to be called when certain events occur that require
administrative attention --- this would be a good case for that.
Administrators could configure shell scripts to be run
Marc G. Fournier wrote:
On Sat, 27 Sep 2003, Bruce Momjian wrote:
I have been thinking it might be time to start allowing external
programs to be called when certain events occur that require
administrative attention --- this would be a good case for that.
Administrators could
-Original Message-
(B From: Tom Lane
(B
(B Bruce Momjian [EMAIL PROTECTED] writes:
(B Tom Lane wrote:
(B You're not considering the possibility of a transient communication
(B failure.
(B
(B Can't the master re-send the request after a timeout?
(B
(B Not "it can", but "it
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Sat, 27 Sep 2003, Bruce Momjian wrote:
I have been thinking it might be time to start allowing external
programs to be called when certain events occur that require
administrative attention --- this would be a good case for that.
Kevin Brown wrote:
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Sat, 27 Sep 2003, Bruce Momjian wrote:
I have been thinking it might be time to start allowing external
programs to be called when certain events occur that require
administrative attention --- this
Zeugswetter Andreas SB SD wrote:
From our previous discussion of 2-phase commit, there was concern that
the failure modes of 2-phase commit were not solvable. However, I think
multi-master replication is going to have similar non-solvable failure
modes, yet people still want
Bruce Momjian [EMAIL PROTECTED] writes:
Could we allow slaves to check if the backend is still alive, perhaps by
asking the postmaster, similar to what we do with the cancel signal ---
that way, the slave would never time out and always wait if the master
was alive.
You're not considering the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Could we allow slaves to check if the backend is still alive, perhaps by
asking the postmaster, similar to what we do with the cancel signal ---
that way, the slave would never time out and always wait if the master
was alive.
On Fri, 26 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Could we allow slaves to check if the backend is still alive, perhaps by
asking the postmaster, similar to what we do with the cancel signal ---
that way, the slave would never time out and always wait if the
On Fri, 26 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Could we allow slaves to check if the backend is still alive, perhaps by
asking the postmaster, similar to what we do with the cancel signal ---
that way, the slave would never time out and always wait if the
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
if we are talking two computers sitting next to each other on a switch,
you'd expect those to be low ... but if you were talking about two
seperate geographical locations (and yes, I realize you are adding lag to
the mix
Patrick Welche wrote:
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
if we are talking two computers sitting next to each other on a switch,
you'd expect those to be low ... but if you were talking about two
seperate geographical locations (and yes, I realize you
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You're not considering the possibility of a transient communication
failure.
Can't the master re-send the request after a timeout?
Not it can, but it has to. The master *must* keep hold of that
request forever (or until the slave
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You're not considering the possibility of a transient communication
failure.
Can't the master re-send the request after a timeout?
Not it can, but it has to. The master *must* keep hold of that
request forever
On Fri, 26 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You're not considering the possibility of a transient communication
failure.
Can't the master re-send the request after a timeout?
Not it can, but it has to. The master *must* keep hold of
[EMAIL PROTECTED] (Bruce Momjian) writes:
Patrick Welche wrote:
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
if we are talking two computers sitting next to each other on a switch,
you'd expect those to be low ... but if you were talking about two
seperate
1 - 100 of 117 matches
Mail list logo
