On Wed, 2009-05-27 at 12:08 -0400, Bruce Momjian wrote:
Ideally someone would have
taken ownership of the issue, summarized the email conclusions, gotten
a patch together, and submitted it for application.
Just a further comment on this, based upon the patch Heikki recently
committed.
I
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without extending
the interface between the backend and restore_command. We've discussed
many methods and there's always some nasty corner-case like that.
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without extending
the interface between the backend and restore_command. We've discussed
many
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without
extending
the interface between the backend and
Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without
extending
the interface
On Wed, 2009-05-27 at 09:48 -0400, Bruce Momjian wrote:
We are not going to improve unless we face our faults.
True. Who or what is at fault, in your opinion?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list
Bruce Momjian wrote:
Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
I think the big frustration is that this issue was first brought up
March 25 and it took two months to resolve it, at which point we were in
beta. I think many hoped a better
On Wed, 2009-05-27 at 09:51 -0400, Bruce Momjian wrote:
Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
I think the big frustration is that this issue was first brought up
March 25 and it took two months to resolve it, at
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:48 -0400, Bruce Momjian wrote:
We are not going to improve unless we face our faults.
True. Who or what is at fault, in your opinion?
Well, we knew there was an issue but we didn't finalize our conclusions
and address it as best we could
On Wed, 2009-05-27 at 12:08 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:48 -0400, Bruce Momjian wrote:
We are not going to improve unless we face our faults.
True. Who or what is at fault, in your opinion?
Well, we knew there was an issue but we
Simon Riggs wrote:
My experience is that consensus/votes will be overruled by final
committer, if they disagree,
That's a fairly strong statement. I can't think of an occasion when this
has happened on any matter of significance, and I can remember many
times when Tom, Bruce and others
On Wed, May 27, 2009 at 1:14 PM, Andrew Dunstan and...@dunslane.net wrote:
Simon Riggs wrote:
My experience is that consensus/votes will be overruled by final
committer, if they disagree,
That's a fairly strong statement. I can't think of an occasion when this has
happened on any matter of
On Wed, 2009-05-27 at 13:14 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
My experience is that consensus/votes will be overruled by final
committer, if they disagree,
That's a fairly strong statement.
I was attempting to be open and honest to allow us to face our faults,
as
On Wed, 2009-05-27 at 17:39 +0300, Heikki Linnakangas wrote:
I agree we could've should've handled this more promptly, and I'll take
my part of the blame for that. I let the various proposed patches sit
for long times before reviewing them thoroughly, partly because I was
busy and partly
Robert Haas wrote:
Tom and Bruce do give way before a clear consensus, but on the other
hand I think Simon is right that there was never much chance of
getting anything committed here without Heikki's endorsement, which
was slow in coming by his own admission. (I'm not in any way saying
he
On Thu, 2009-05-14 at 23:31 +0300, Heikki Linnakangas wrote:
I've finally committed changes to pg_standby.
That was a good team effort. Thanks for committing.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing
Hi,
Sorry for the delay.
On Thu, May 14, 2009 at 6:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
but before we go to DB_IN_PRODUCTION?
I think it can be either, so I'll go with your proposal.
I also think so.
(I'm aware Fujii-san is asleep right now, so we should expect another
On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
This whole thing can be considered to be a new feature.
recovery.conf will contain a new optional parameter:
recovery_end_command (string)
Implemented.
Some possibility
Hi,
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
This whole thing can be considered to be a new feature.
recovery.conf will contain a new
Fujii Masao wrote:
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
This whole thing can be considered to be a new feature.
recovery.conf will contain
On Fri, 2009-05-15 at 03:49 +0900, Fujii Masao wrote:
Hi,
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
This whole thing can be considered
I've finally committed Simon's recovery_end_command patch, as well as
the changes to pg_standby. There's now smart and fast failover modes,
chosen by the content of the trigger file, smart mode is the default. A
fast trigger file is truncated, turning it into a smart trigger for
subsequent
Hi,
On Fri, May 15, 2009 at 5:31 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I've finally committed Simon's recovery_end_command patch, as well as the
changes to pg_standby. There's now smart and fast failover modes, chosen by
the content of the trigger file, smart mode
Hi,
On Tue, May 12, 2009 at 8:15 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This is getting complicated, though. I guess it would be enough to
document
Fujii Masao wrote:
On Tue, May 12, 2009 at 8:15 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Here's another idea: Let's modify xlog.c so that when the server asks for
WAL file X, and restore_command returns not found, the server will not ask
for any WAL files = X again (in
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without extending
the interface between the backend and restore_command. We've discussed
many methods and there's always some nasty corner-case like that.
I think we should
On Wed, 2009-05-13 at 13:01 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without extending
the interface between the backend and restore_command. We've discussed
many methods and there's
Simon Riggs si...@2ndquadrant.com writes:
I will set-up pg_standby as an external module and we can change it from
there. No more discussions-for-8.4 and I can update as required to
support each release. So let's just remove it from contrib and be done.
Huh? The proposed fix involves a
Simon Riggs wrote:
I will set-up pg_standby as an external module and we can change it from
there. No more discussions-for-8.4 and I can update as required to
support each release. So let's just remove it from contrib and be done.
Counterthoughts?
We're in Beta. You can't just go yanking
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without extending
the interface between the backend and restore_command. We've discussed
many methods and there's always some nasty corner-case like that.
I
On Wed, 2009-05-13 at 14:14 -0400, Andrew Dunstan wrote:
pg_standby is useful and needs to be correct. And its existence as a
standard module is one of the things that has made me feel confident
about recommending people to use the PITR stuff. I'll be very annoyed if
it were to get pulled.
On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
I think we should fix it for 8.4.
Agreed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Simon Riggs wrote:
On Wed, 2009-05-13 at 13:01 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Does someone want to take a stab at writing a patch for that?
No, not if there is a likelihood the work would be wasted.
There always is.
(I would've wrote
Andrew Dunstan wrote:
We're in Beta. You can't just go yanking stuff like that. Beta testers
will be justifiably very annoyed.
Please calm down.
pg_standby is useful and needs to be correct. And its existence as a
standard module is one of the things that has made me feel confident
about
On Wed, 2009-05-13 at 14:14 -0400, Andrew Dunstan wrote:
pg_standby is useful and needs to be correct.
My suggestion was designed to provide this. A misunderstanding.
And its existence as a
standard module is one of the things that has made me feel confident
about recommending people to
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
Does this conclusion mean that changing pg_standby is no longer
on the table for 8.4? It certainly smells more like a new feature
than a bug fix.
This whole thing can be considered to be a new feature. It's
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
That's a lot more drastic change to make in beta. Besides, the proposed
fix required backend changes. I think we should keep it in contrib. (At
least for this release: If we get more integrated replication options in
8.5, that
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
That's a lot more drastic change to make in beta. Besides, the proposed
fix required backend changes. I think we should keep it in contrib. (At
least for this release: If we get more integrated replication
On Wed, 2009-05-13 at 14:53 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
Does this conclusion mean that changing pg_standby is no longer
on the table for 8.4? It certainly smells more like a new feature
than a bug fix.
This
Simon Riggs wrote:
On Wed, 2009-05-13 at 14:53 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
Does this conclusion mean that changing pg_standby is no longer
on the table for 8.4? It certainly smells more like a new feature
than a bug
On Wed, 2009-05-13 at 15:05 -0400, Andrew Dunstan wrote:
Frankly, if anything it should move from contrib to the core proper. I
regard it as an essential utility, not an optional extra.
I like that idea.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and
On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
This whole thing can be considered to be a new feature.
recovery.conf will contain a new optional parameter:
recovery_end_command (string)
This parameter specifies a shell command that will be executed once only
at the end of
Simon Riggs si...@2ndquadrant.com writes:
recovery_end_command is performed *after* the UpdateControlFile() once
the we are DB_IN_PRODUCTION.
Hmm, shouldn't it be after the last checkpoint but before we go to
DB_IN_PRODUCTION? I have to admit I've not been following this closely
though, so I
On Wed, 2009-05-13 at 16:47 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
recovery_end_command is performed *after* the UpdateControlFile() once
the we are DB_IN_PRODUCTION.
Hmm, shouldn't it be after the last checkpoint
Definitely.
but before we go to
Fujii Masao wrote:
On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This is getting complicated, though. I guess it would be enough to document
that you mustn't copy any extra files into pg_xlog if you use a fast
trigger.
Agreed. I added this note
On Tue, 2009-05-12 at 14:15 +0300, Heikki Linnakangas wrote:
Here's another idea: Let's modify xlog.c so that when the server asks
for WAL file X, and restore_command returns not found, the server
will not ask for any WAL files = X again (in that recovery session).
Presumably if X doesn't
Simon Riggs wrote:
On Tue, 2009-05-12 at 14:15 +0300, Heikki Linnakangas wrote:
Here's another idea: Let's modify xlog.c so that when the server asks
for WAL file X, and restore_command returns not found, the server
will not ask for any WAL files = X again (in that recovery session).
On Tue, 2009-05-12 at 14:38 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Tue, 2009-05-12 at 14:15 +0300, Heikki Linnakangas wrote:
Here's another idea: Let's modify xlog.c so that when the server asks
for WAL file X, and restore_command returns not found, the server
will
Fujii Masao wrote:
On Wed, Apr 22, 2009 at 4:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao masao.fu...@gmail.com
wrote:
I'd like to propose another simple idea; pg_standby deletes the
trigger file
Hi,
On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This is getting complicated, though. I guess it would be enough to document
that you mustn't copy any extra files into pg_xlog if you use a fast
trigger.
Agreed. I added this note into document.
On Tue, 2009-04-21 at 09:59 -0700, David Fetter wrote:
On Tue, Apr 21, 2009 at 12:25:50PM +0100, Simon Riggs wrote:
No, removing trigger file as soon as a non-existant file is
requested still seems simpler than deleting it whenever a timeline
history file is requested.
If you do
Simon Riggs wrote:
On Mon, 2009-04-20 at 17:47 +0300, Heikki Linnakangas wrote:
At the end of archive recovery, the server always probes for the
timeline by requesting history files until it fails to find one. That
probing should remove the trigger file if it hasn't been removed by
then.
On Tue, 2009-04-21 at 14:17 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Mon, 2009-04-20 at 17:47 +0300, Heikki Linnakangas wrote:
At the end of archive recovery, the server always probes for the
timeline by requesting history files until it fails to find one. That
probing
Simon Riggs wrote:
If you do this, then you would have to change the procedure written into
the 8.3 docs also. Docs aren't backpatchable.
What you propose is *better* than raw pg_standby is now, but still not
enough in all cases, as I think you know.
No, I don't. What is the case where it
Hi,
On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
If you do this, then you would have to change the procedure written into
the 8.3 docs also. Docs aren't backpatchable.
What you propose is *better* than raw pg_standby is
On Tue, 2009-04-21 at 14:28 +0300, Heikki Linnakangas wrote:
Simple isn't the requirement here, is it?
Simplicity is always a virtue, because it leads to maintainability.
Simple enough is a virtue. Less than that is not...
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL
Fujii Masao wrote:
On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
What you propose is *better* than raw pg_standby is now, but still not
enough in all cases, as I think you know.
No, I don't. What is the case where it doesn't
Fujii Masao wrote:
Hi,
On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
If you do this, then you would have to change the procedure written into
the 8.3 docs also. Docs aren't backpatchable.
What you propose is
On Tue, 2009-04-21 at 15:55 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
What you propose is *better* than raw pg_standby is now, but still not
enough in all cases,
Andreas Pflug wrote:
I'm a little confused. After pg_standby returned non-zero as indication
for end-of-recovery, the startup process shouldn't request another file
from pg_standby, right?
Non-zero return value from restore_command doesn't mean end-of-recovery,
it means file-not-found. The
On Tue, Apr 21, 2009 at 12:25:50PM +0100, Simon Riggs wrote:
No, removing trigger file as soon as a non-existant file is
requested still seems simpler than deleting it whenever a timeline
history file is requested.
If you do this, then you would have to change the procedure written
into
Fujii Masao wrote:
Hi,
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao masao.fu...@gmail.com wrote:
I'd like to propose another simple idea; pg_standby deletes the
trigger file *whenever* the nextWALfile is a timeline history file.
A timeline history file is restored at the end of recovery, so
Hi,
Thanks for reviewing the patch!
On Wed, Apr 22, 2009 at 4:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
Hi,
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao masao.fu...@gmail.com
wrote:
I'd like to propose another simple idea; pg_standby deletes
Fujii Masao wrote:
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao masao.fu...@gmail.com wrote:
I'd like to propose another simple idea; pg_standby deletes the
trigger file *whenever* the nextWALfile is a timeline history file.
A timeline history file is restored at the end of recovery, so it's
Hi,
On Mon, Apr 20, 2009 at 6:06 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao masao.fu...@gmail.com
wrote:
I'd like to propose another simple idea; pg_standby deletes the
trigger file *whenever* the
Fujii Masao wrote:
On Mon, Apr 20, 2009 at 6:06 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
What's wrong with just this: (ignoring the missing fast option)
--- a/contrib/pg_standby/pg_standby.c
+++ b/contrib/pg_standby/pg_standby.c
@@ -552,8 +552,6 @@ main(int argc, char
Hi Simon,
Thanks for the comments!
On Thu, Apr 16, 2009 at 2:56 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-04-15 at 17:02 +0900, Fujii Masao wrote:
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao masao.fu...@gmail.com wrote:
I'd like to propose another simple idea; pg_standby
Hi,
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao masao.fu...@gmail.com wrote:
I'd like to propose another simple idea; pg_standby deletes the
trigger file *whenever* the nextWALfile is a timeline history file.
A timeline history file is restored at the end of recovery, so it's
guaranteed that
On Wed, 2009-04-15 at 17:02 +0900, Fujii Masao wrote:
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao masao.fu...@gmail.com wrote:
I'd like to propose another simple idea; pg_standby deletes the
trigger file *whenever* the nextWALfile is a timeline history file.
A timeline history file is
On Mon, 2009-04-13 at 14:52 +0900, Fujii Masao wrote:
A lookahead (the +1) may have pg_standby get stuck as follows.
Am I missing something?
1. the trigger file containing smart is created.
2. pg_standby is executed.
2-1. nextWALfile is restored.
2-2. the trigger file is deleted
Hi,
On Tue, Apr 14, 2009 at 6:35 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-04-13 at 14:52 +0900, Fujii Masao wrote:
A lookahead (the +1) may have pg_standby get stuck as follows.
Am I missing something?
1. the trigger file containing smart is created.
2. pg_standby is
Hi,
On Mon, Apr 13, 2009 at 2:52 PM, Fujii Masao masao.fu...@gmail.com wrote:
But, a lookahead nextWALfile seems to work fine.
if (triggered)
{
if (smartMode nextWALfile exists)
exit(0)
else
{
delete trigger file
exit(1)
}
}
Umm... in this algorithm,
On Mon, Apr 13, 2009 at 7:52 AM, Fujii Masao masao.fu...@gmail.com wrote:
1. the trigger file containing smart is created.
2. pg_standby is executed.
2-1. nextWALfile is restored.
2-2. the trigger file is deleted because nextWALfile+1 doesn't exist.
3. the restored nextWALfile is
Hi,
On Mon, Apr 13, 2009 at 7:21 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Mon, Apr 13, 2009 at 7:52 AM, Fujii Masao masao.fu...@gmail.com wrote:
1. the trigger file containing smart is created.
2. pg_standby is executed.
2-1. nextWALfile is restored.
2-2. the trigger file
On Mon, 2009-04-13 at 14:52 +0900, Fujii Masao wrote:
if (triggered)
{
if (smartMode nextWALfile exists)
exit(0)
else
{
delete trigger file
exit(1)
}
}
This looks to be the correct one.
--
Simon Riggs www.2ndQuadrant.com
Hi,
On Fri, Apr 10, 2009 at 6:31 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
One idea to solve this problem is to tell pg_standby as a
command-line argument about whether the trigger file can be
removed. That
Hi,
On Sat, Apr 11, 2009 at 1:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
Fujii-san,
I like the new patch using the content of the file to determine the
mode. Much easier to use at failover time.
On Fri, 2009-04-10 at 12:47 +0900, Fujii Masao wrote:
One problem with this patch is
On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
One idea to solve this problem is to tell pg_standby as a
command-line argument about whether the trigger file can be
removed. That parameter value can be set to 'true' when the last
applied record is re-fetched. Though
Fujii-san,
I like the new patch using the content of the file to determine the
mode. Much easier to use at failover time.
On Fri, 2009-04-10 at 12:47 +0900, Fujii Masao wrote:
One problem with this patch is that in smart mode, the trigger file is not
deleted. That's different from current
Fujii Masao wrote:
Hi,
On Wed, Apr 8, 2009 at 6:56 AM, Guillaume Smet guillaume.s...@gmail.com wrote:
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao masao.fu...@gmail.com wrote:
Here is the patch;
- Smart failover is chosen if the trigger file labeled smart or
an empty one exists.
- Fast
Hi,
On Thu, Apr 9, 2009 at 9:47 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
+ if (strspn(buf, smart) == 5 strncmp(buf, smart, 5) == 0)
+ {
The strspn() call seems pointless here.
OK, I'll get rid of it.
One problem with this patch is that in smart mode,
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao masao.fu...@gmail.com wrote:
Here is the patch;
- Smart failover is chosen if the trigger file labeled smart or
an empty one exists.
- Fast failover is chosen if the trigger file labeled fast exists,
the signal (SIGUSR1 or SIGINT) is received or
Hi,
On Fri, Mar 27, 2009 at 11:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2009-03-27 at 10:25 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Simon Riggs wrote:
If we go with this, I would suggest we make *neither* the default by
removing -t, and adopting two
On Thu, Mar 26, 2009 at 4:54 AM, Guillaume Smet guillaume.s...@gmail.comwrote:
Hi Simon.
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs si...@2ndquadrant.com
wrote:
Earlier, we discussed having a single trigger file that contains an
option rather than two distinct trigger files. That
Hi,
On Fri, Mar 27, 2009 at 9:49 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Uh oh, that's going to be quite tricky with signals. Remember that
pg_standby is called for each file. A trigger file persists until it's
deleted, but a signal will only be received by the
Simon Riggs wrote:
If we go with this, I would suggest we make *neither* the default by
removing -t, and adopting two new options: something like -f == fast
failover, -p == patient failover.
-m smart|fast|immediate :-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Fri, 2009-03-27 at 13:56 +0200, Peter Eisentraut wrote:
Simon Riggs wrote:
If we go with this, I would suggest we make *neither* the default by
removing -t, and adopting two new options: something like -f == fast
failover, -p == patient failover.
-m smart|fast|immediate :-)
Yes, a
On Fri, Mar 27, 2009 at 12:56 PM, Peter Eisentraut pete...@gmx.net wrote:
Simon Riggs wrote:
If we go with this, I would suggest we make *neither* the default by
removing -t, and adopting two new options: something like -f == fast
failover, -p == patient failover.
-m smart|fast|immediate
On Fri, Mar 27, 2009 at 3:38 AM, Fujii Masao masao.fu...@gmail.com wrote:
OK, I'll change the patch as Simon suggested; removing -t and adding
two new options: -f = fast failover (existing behavior), -p patient failover.
Also I'll default the patient failover, so it's performed when the signal
Fujii Masao wrote:
On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
I like the idea of removing -t and adding 2 new options so that people
are warned about the intended behavior.
OK, I'll
On Fri, 2009-03-27 at 13:19 +0100, Guillaume Smet wrote:
On Fri, Mar 27, 2009 at 12:56 PM, Peter Eisentraut pete...@gmx.net wrote:
Simon Riggs wrote:
If we go with this, I would suggest we make *neither* the default by
removing -t, and adopting two new options: something like -f == fast
Peter Eisentraut pete...@gmx.net writes:
Simon Riggs wrote:
If we go with this, I would suggest we make *neither* the default by
removing -t, and adopting two new options: something like -f == fast
failover, -p == patient failover.
-m smart|fast|immediate :-)
+1 for using a -m something
On Fri, 2009-03-27 at 10:25 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Simon Riggs wrote:
If we go with this, I would suggest we make *neither* the default by
removing -t, and adopting two new options: something like -f == fast
failover, -p == patient failover.
Fujii Masao wrote:
On Thu, Mar 26, 2009 at 12:48 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Wed, Mar 25, 2009 at 2:59 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I find it hard to imagine a use case for the existing default
behavior.
I thought a bit about it and I think
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao masao.fu...@gmail.com wrote:
What does the default mean? You mean that new trigger should use
the existing trigger option character (-t)?
Yes, that's my point.
I understand it seems weird to switch the options but I'm pretty sure
a lot of persons
Hi,
Guillaume Smet wrote:
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao masao.fu...@gmail.com wrote:
What does the default mean? You mean that new trigger should use
the existing trigger option character (-t)?
Yes, that's my point.
I understand it seems weird to switch the options but I'm
On Thu, 2009-03-26 at 08:32 +0100, Guillaume Smet wrote:
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao masao.fu...@gmail.com wrote:
What does the default mean? You mean that new trigger should use
the existing trigger option character (-t)?
Yes, that's my point.
I understand it seems
Hi Simon.
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
Earlier, we discussed having a single trigger file that contains an
option rather than two distinct trigger files. That design is better
because it allows the user to choose at failover time, rather than
Hi,
On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
Hi Simon.
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
Earlier, we discussed having a single trigger file that contains an
option rather than two distinct trigger files. That
Hi,
Current pg_standby is dangerous because the presence of the trigger
file causes recovery to end whether or not the next WAL file is available.
So, some *available* transactions may be lost at failover. Such danger
will become high if the standby server has not caught up with the primary.
1 - 100 of 107 matches
Mail list logo
