From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | olly(at)lfix(dot)co(dot)uk, nferrier(at)tapsellferrier(dot)co(dot)uk, pgman(at)candle(dot)pha(dot)pa(dot)us, peter_e(at)gmx(dot)net, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Re: syslog logging setup broken? |
Date: | 2001-02-06 03:39:46 |
Message-ID: | 20010206123946O.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
> > If postmaster is being started by init, it should not need nohup, because
> > init never exits and postmaster is not going to get shutdown unexpectedly.
>
> On the other hand, when pg_ctl is invoked by hand, it probably is a bug
> that it fails to use nohup. Perhaps this is a reason why pg_ctl should
> not be made into a substitute for a startup script?
If pg_ctl unconditionally use nohup, it might be a performance penalty
as Oliver mentioned.
> nohup has a performance cost, in that (at least on Linux) it automatically
> nices (lowers the priority of) the process. You may not want the
> priority lowered...
Moreover if postmaster detaches itself to be a deamon, nohup is not
necessary at all.
BTW, for the startup script, I don't think we need to use pg_ctl.
Invoking postmaster directry seems enough for me. The only reason for
using pg_ctl to start postmaster is waiting for postmaster up and
running. In most cases the time to recover DB would not be so
long. And if the recovery took too long time, we would not want to be
blocked in the middle of the boot sequence anyway.
Comments?
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2001-02-06 06:11:31 | single a suggestion |
Previous Message | Bruce Momjian | 2001-02-06 02:11:23 | Re: Large data field causes a backend crash. |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-02-06 04:31:31 | Re: Foreign Key issue - pg_shadow |
Previous Message | Tom Lane | 2001-02-06 03:08:49 | Re: 7.1 beta 3 CHANGES FOR QNX |