* Fujii Masao (masao.fujii@gmail.com) wrote:
> On Tue, Feb 15, 2011 at 2:10 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > * You removed trigger_file from the list in
> > doc/src/sgml/high-availability.sgml and I'm not sure I agree with
> > that. It's still perfectly valid and could be used by someone
> > instead of pg_ctl promote. I'd recommend two things:
> > - Adding comments into this recovery.conf snippet
>
> Adding the following is enough?
>
> +# NOTE that if you plan to use "pg_ctl promote" command to promote
> +# the standby, no trigger file needs to be specified.
No.. I was thinking of having comments throughout the whole file,
similar to what we have for postgresql.conf.sample. I realize it's an
example in the docs, but people are likely to copy & paste it into their
own files.
> > - Adding a comment indicationg that trigger_file is only needed if
> > you're not using pg_ctl promote.
>
> Where should I add such a comment?
This was still in the example recovery.conf in high-availability.sgml.
> > * I'm not happy that pg_ctl.c doesn't #include something which defines
> > all the file names which are used, couldn't we use a header which
> > makes sense and is pulled in by pg_ctl.c and xlog.c to #define all of
> > these? Still, that's not really the fault of this patch.
>
> That would make sense. But I'm not sure that's possible. As a trial,
> I added '#include "access/xlog.h"' into pg_ctl.c and compiled the source,
> but I got many compilation errors. So probably hacking Makefiles is
> required to do that. Do you know where should be changed?
No, I wouldn't expect that to work.. I would have thought something
that was already included in the necessary places, eg, miscadmin.h.
> > * I'm a bit worried that there's just only so many USR signals that we
> > can send and it looks like we're burning another one here. Should we
> > be considering a better way to do this?
>
> You're worried about the case where users wrongly send the SIGUSR2
> to the startup process, and then the standby is brought up to the master
> unexpectedly?
No.. My concern was that it looked like we were adding a meaning to
SIGUSR2 which might make it unavailable for other uses later, and at
least according to man 7 signal on my system, there's only 2
User-defined signals available (SIGUSR1 and SIGUSR2)..
I just wouldn't want to use up something which is a finite resource
without good cause, in case we have a need for it later. Now, perhaps
that's not happening and my concern is unfounded.
Thanks,
Stephen