Re: pg_ctl failover Re: Latches, signals, and waiting - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pg_ctl failover Re: Latches, signals, and waiting
Date
Msg-id 20110214171041.GK4116@tamriel.snowman.net
Whole thread Raw
In response to Re: pg_ctl failover Re: Latches, signals, and waiting  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: pg_ctl failover Re: Latches, signals, and waiting  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Fujii,

* Fujii Masao (masao.fujii@gmail.com) wrote:
> Yeah, I rebased the patch to the current git master and attached it.

Reviewing this, I just had a couple of comments and questions.  Overall,
I think it looks good and hence will be marking it 'Ready for
Committer'.
* You removed trigger_file from the list in  doc/src/sgml/high-availability.sgml and I'm not sure I agree with  that.
It'sstill perfectly valid and could be used by someone  instead of pg_ctl promote.  I'd recommend two things:  - Adding
commentsinto this recovery.conf snippet  - Adding a comment indicationg that trigger_file is only needed if you're not
usingpg_ctl promote.
 
* I'm not happy that pg_ctl.c doesn't #include something which defines  all the file names which are used, couldn't we
usea header which  makes sense and is pulled in by pg_ctl.c and xlog.c to #define all of  these?  Still, that's not
reallythe fault of this patch.
 
* 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
anotherone here.  Should we  be considering a better way to do this?
 
      Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: why two dashes in extension load files
Next
From: Tom Lane
Date:
Subject: Re: why two dashes in extension load files