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 ra
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
>
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 part
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,
On Wed, May 27, 2009 at 1:14 PM, 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 can't think of an occasion when this has
> happened on any matter of significan
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, 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 i
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 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
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 i
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 (p
Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Heikki Linnakangas writes:
> > > > > I don't think we're going to get this to work reliably without
> > > > > extending
> > > > > the interface between the bac
Simon Riggs wrote:
>
> On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Heikki Linnakangas 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 discu
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Heikki Linnakangas 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 alw
Tom Lane wrote:
> Heikki Linnakangas 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 leav
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 li
Hi,
On Fri, May 15, 2009 at 5:31 AM, Heikki Linnakangas
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 is the default. A "fast" trigger
>
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
On Fri, 2009-05-15 at 03:49 +0900, Fujii Masao wrote:
> Hi,
>
> On Fri, May 15, 2009 at 12:36 AM, Simon Riggs 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 b
Fujii Masao wrote:
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs 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 optional parame
Hi,
On Fri, May 15, 2009 at 12:36 AM, Simon Riggs 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 optional parame
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 poss
Hi,
Sorry for the delay.
On Thu, May 14, 2009 at 6:04 AM, Simon Riggs 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
> viewpoint before tomorro
On Wed, 2009-05-13 at 16:47 -0400, Tom Lane wrote:
> Simon Riggs 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 DB_IN_PRODUCTION?
I thin
Simon Riggs 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 may be missing someth
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 reco
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 Supp
Simon Riggs wrote:
On Wed, 2009-05-13 at 14:53 -0400, Tom Lane wrote:
Heikki Linnakangas 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 considere
On Wed, 2009-05-13 at 14:53 -0400, Tom Lane wrote:
> Heikki Linnakangas 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 cons
Tom Lane wrote:
Heikki Linnakangas 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 would be a good ti
Heikki Linnakangas 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 would be a good time to move pg_s
Heikki Linnakangas 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 working as
> designed. But peopl
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
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 r
Simon Riggs wrote:
On Wed, 2009-05-13 at 13:01 -0400, Tom Lane wrote:
Heikki Linnakangas 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 the patch myself right away, but I'm
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 sub
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 pull
Tom Lane wrote:
Heikki Linnakangas 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 leave back-branches 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
Simon Riggs 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 backend change, so I don'
On Wed, 2009-05-13 at 13:01 -0400, Tom Lane wrote:
> Heikki Linnakangas 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
Heikki Linnakangas 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 leave back-branches as is, and g
Fujii Masao wrote:
On Tue, May 12, 2009 at 8:15 PM, 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). Presumabl
Hi,
On Tue, May 12, 2009 at 8:15 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
>> 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 i
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 serv
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).
Presum
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 do
Fujii Masao wrote:
On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
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.
Attached is the upd
Hi,
On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
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.
Attached is the updated patch.
Fujii Masao wrote:
On Wed, Apr 22, 2009 at 4:27 AM, Heikki Linnakangas
wrote:
Fujii Masao wrote:
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao
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
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.
> >
> >
Hi,
Thanks for reviewing the patch!
On Wed, Apr 22, 2009 at 4:27 AM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> Hi,
>>
>> On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao
>> wrote:
>>>
>>> I'd like to propose another simple idea; pg_standby deletes the
>>> trigger file *whenever* the next
Fujii Masao wrote:
Hi,
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao 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 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
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 ser
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
> > 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.
Fujii Masao wrote:
> Hi,
>
> On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
> 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
Fujii Masao wrote:
On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
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 work?
It's the case which I descri
Hi,
On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
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 now, but still not
>> enoug
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 T
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 does
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
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. It's
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. It's a bit coinc
Fujii Masao wrote:
On Mon, Apr 20, 2009 at 6:06 PM, Heikki Linnakangas
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 **argv)
break;
Hi,
On Mon, Apr 20, 2009 at 6:06 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao
>> wrote:
>>>
>>> I'd like to propose another simple idea; pg_standby deletes the
>>> trigger file *whenever* the nextWALfile is a timeline history file.
>>> A t
Fujii Masao wrote:
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao 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 the trig
Hi Simon,
Thanks for the comments!
On Thu, Apr 16, 2009 at 2:56 AM, Simon Riggs wrote:
>
> On Wed, 2009-04-15 at 17:02 +0900, Fujii Masao wrote:
>
>> On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao wrote:
>> > I'd like to propose another simple idea; pg_standby deletes the
>> > trigger file *whene
On Wed, 2009-04-15 at 17:02 +0900, Fujii Masao wrote:
> On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao 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 e
Hi,
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao 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 the trigger file
Hi,
On Tue, Apr 14, 2009 at 6:35 PM, Simon Riggs 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 executed.
>>
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 d
Hi,
On Mon, Apr 13, 2009 at 2:52 PM, Fujii Masao 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, the tri
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 Mon, Apr 13, 2009 at 7:21 PM, Guillaume Smet
wrote:
> On Mon, Apr 13, 2009 at 7:52 AM, Fujii Masao 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 do
On Mon, Apr 13, 2009 at 7:52 AM, Fujii Masao 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 applied.
> 4. pg_stan
Hi,
On Sat, Apr 11, 2009 at 1:31 AM, Simon Riggs 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 that in smart
Hi,
On Fri, Apr 10, 2009 at 6:31 PM, Guillaume Smet
wrote:
> On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao 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
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 curre
On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao 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 pg_standby is call
Hi,
On Thu, Apr 9, 2009 at 9:47 PM, Heikki Linnakangas
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, the trigger file is no
Fujii Masao wrote:
Hi,
On Wed, Apr 8, 2009 at 6:56 AM, Guillaume Smet wrote:
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao 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 "fa
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao 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 the wait timeo
Hi,
On Fri, Mar 27, 2009 at 11:36 PM, Simon Riggs wrote:
>
> On Fri, 2009-03-27 at 10:25 -0400, Tom Lane wrote:
>> Peter Eisentraut 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: somethin
On Thu, Mar 26, 2009 at 4:54 AM, Guillaume Smet wrote:
> Hi Simon.
>
> On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs
> 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
Hi,
On Fri, Mar 27, 2009 at 9:49 PM, Heikki Linnakangas
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 pg_standby instance that
> happens to b
On Fri, 2009-03-27 at 10:25 -0400, Tom Lane wrote:
> Peter Eisentraut 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
Peter Eisentraut 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" type of s
On Fri, 2009-03-27 at 13:19 +0100, Guillaume Smet wrote:
> On Fri, Mar 27, 2009 at 12:56 PM, 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
> >>
Fujii Masao wrote:
On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet
wrote:
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs 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 change the patch as Simon suggested; removing
On Fri, Mar 27, 2009 at 3:38 AM, Fujii Masao 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
> (SIGINT or SIGUSR
On Fri, Mar 27, 2009 at 12:56 PM, 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 :-)
Th
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 :-)
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 m
Hi,
On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet
wrote:
> Hi Simon.
>
> On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs 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
Hi Simon.
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs 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
> making a binding decis
On Thu, 2009-03-26 at 08:32 +0100, Guillaume Smet wrote:
> On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao 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 swit
Hi,
Guillaume Smet wrote:
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao 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 p
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao 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 currently using -t w
Fujii Masao wrote:
On Thu, Mar 26, 2009 at 12:48 AM, Guillaume Smet
wrote:
On Wed, Mar 25, 2009 at 2:59 PM, Kevin Grittner
wrote:
I find it hard to imagine a use case for the existing default
behavior.
I thought a bit about it and I think it can be useful when your
priority is the availabili
1 - 100 of 108 matches
Mail list logo
