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 progress
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.
>
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. Perh
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 i
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 pro
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 wa
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
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 wor
Jan Wieck wrote:
> 2PC is not too slow in normal operations when everything is purring
> like little kittens and you're just wasting your excess bandwidth on
> it. The point is that it behaves horrible and like a dirty backstreet
> cat at the time when things go wrong ... basically it's a neat thin
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 wit
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 cras
> 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
> -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:53
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'
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
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
wh
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
> -Original Message-
> From: Satoshi Nagayasu [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 10, 2003 12:26 PM
> To: Andrew Sullivan
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] 2-phase commit
>
> Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> >
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 bette
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 reas
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
--
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 m
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, name
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 s
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
> 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 b
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
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 sat
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 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 ye
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
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 impl
> > 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 ins
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?
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? T
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 who
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
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 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 ...
>
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 scr
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 appr
[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'
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 Ca
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?
http://www.post
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 gra
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 transac
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 co
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 w
> -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
> 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 noti
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 sol
> > 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
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, b
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 so
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 failu
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
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 ...
>
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 lik
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
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 pha
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
> > > 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
---
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
> i
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", a
> > > 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
> 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
> -Original Message-
> From: Zeugswetter Andreas SB SD [mailto:[EMAIL PROTECTED]
> >
> > Example:
> >
> > Master Slave
> > -- -
> > commit ready-->
>
> This is the commit for phase 1. This commit is allowed to return all
> sorts of err
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
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 sl
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 reque
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 understandi
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 operation
> > > > 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 be
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
(Bmuc
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 coordinator(slave)' side]
(B> >1) Aft
(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> >
(
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 coordinator(slave)' side]
(B> >1) Aft
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
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 bet
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-se
> > 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 postmaste
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 f
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
> > > > administra
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 go
> -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
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
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
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 communi
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 cou
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 p
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 can
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
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 master
time out a
> Not "it can", but "it has to". The master *must* keep hold of that
> request forever (or until the slave responds, or until we reconfigure
> the system not to consider that slave valid anymore). Similarly, the
> slave cannot forget the maybe-committed transaction on pain of not being
> a valid
On Fri, 26 Sep 2003, Christopher Browne wrote:
> [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 th
Marc G. Fournier wrote:
> 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"
> 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 think the answer is sort of easy. A member
> which re-joins wi
On Fri, 2003-09-26 at 13:58, Bruce Momjian wrote:
> 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
On Fri, 26 Sep 2003, Christopher Browne wrote:
> [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
On Fri, Sep 26, 2003 at 02:05:36PM -0400, Tom Lane wrote:
> a valid slave anymore. You can make this work, but the resource costs
> are steep. For instance, in Postgres, you don't get to truncate the WAL
But people who want 2PC are more than willing to pay all that cost.
A
--
Andrew Sull
1 - 100 of 122 matches
Mail list logo
