Thread: syslog by default?
There was a discussion about --enable-syslog by default. What was the consensus? I think this is a good one. -- Tatsuo Ishii
> There was a discussion about --enable-syslog by default. What was the > consensus? I think this is a good one. Yes, I thought we decided it should be the default too. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 11 Sep 2001, Bruce Momjian wrote: > > There was a discussion about --enable-syslog by default. What was the > > consensus? I think this is a good one. > > Yes, I thought we decided it should be the default too. I know it can have an adverse effect on a mail server, is syslog going to give us any performance hits? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Tatsuo Ishii writes: > There was a discussion about --enable-syslog by default. What was the > consensus? I think this is a good one. It would be a good one if we make the blind assumption that syslog() exists on all platforms. That is possible, but not guaranteed. (BeOS, QNX, Cygwin?) The alternative suggestion to turn it off if syslog() is not found makes me wary. These schemes have invariably lead to problems in the past. Recall libpq++ being missed because of false test results, readline support mysteriously disappearing and nobody noticing until Mandrake had shipped their CDs. There are possible scenarios where syslog support could be missed by configure, such as when you need some compat or bsd library. An alternative scheme I wanted to implement for readline is --enable-foo => force feature to be used --disable-foo => force feature not to be used <nothing> => use feature if available but I'm afraid that this would create more confusion than it's worth because a prudent user would specify --enable-foo anyway. I'd rather type a few more things and get predictable behavior from configure rather than relying on it to pick the features for me. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> I know it can have an adverse effect on a mail server, is syslog going > to give us any performance hits? Yes. On some platforms (HP-UX at least) applications can stall ~2s retrying if syslogd is not reading the messages written to its pipe. syslogd also has a reputation for using too much CPU under load, but this is annecdotal only -- I've not seen such a situation myself. Regards, Giles
On Mar 11 Sep 2001 02:07, Bruce Momjian wrote:
> > There was a discussion about --enable-syslog by default. What was the
> > consensus? I think this is a good one.
>
> Yes, I thought we decided it should be the default too.
There was a discusion about log rotation last week, so, where are we going?
Pipe the output of postmaster to a log rotator like apaches logrotate, or are
we going to use syslog and have the syslog log rotator do the rotation?
Just a dought I had.
Saludos... :-)
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica Universidad Nacional
del Litoral
-----------------------------------------------------------------
On Tuesday 11 September 2001 06:14 pm, Martín Marqués wrote: > There was a discusion about log rotation last week, so, where are we going? > Pipe the output of postmaster to a log rotator like apaches logrotate, or > are we going to use syslog and have the syslog log rotator do the rotation? Both have their place. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> Tatsuo Ishii writes: > > > There was a discussion about --enable-syslog by default. What was the > > consensus? I think this is a good one. > > It would be a good one if we make the blind assumption that syslog() > exists on all platforms. That is possible, but not guaranteed. (BeOS, > QNX, Cygwin?) > > The alternative suggestion to turn it off if syslog() is not found makes > me wary. These schemes have invariably lead to problems in the past. > Recall libpq++ being missed because of false test results, readline > support mysteriously disappearing and nobody noticing until Mandrake had > shipped their CDs. There are possible scenarios where syslog support > could be missed by configure, such as when you need some compat or bsd > library. Why are you so worrying about finding syslog() in configure? We have already done lots of function testings. Is there anything special with syslog()? -- Tatsuo Ishii
Tatsuo Ishii writes: > Why are you so worrying about finding syslog() in configure? We have > already done lots of function testings. Is there anything special with > syslog()? All the other functions we test for come with a replacement plan. Either we choose between several similar alternatives (atexit/on_exit), or we link in our own function.o file. But we don't shut off a whole piece of functionality when one goes missing (except in the cases I mentioned). I'm probably being paranoid. But you did ask what became of the idea, and that's what did, as far as I'm concerned... -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Tatsuo Ishii writes: > > > Why are you so worrying about finding syslog() in configure? We have > > already done lots of function testings. Is there anything special with > > syslog()? > > All the other functions we test for come with a replacement plan. Either > we choose between several similar alternatives (atexit/on_exit), or we > link in our own function.o file. But we don't shut off a whole piece of > functionality when one goes missing (except in the cases I mentioned). > > I'm probably being paranoid. But you did ask what became of the idea, and > that's what did, as far as I'm concerned... OK, that makes sense. My only question is how many platforms _don't_ have syslog. If it is only NT and QNX, I think we can live with using it by default if it exists. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sep 12, pgman@candle.pha.pa.us contorted a few electrons to say... Bruce> OK, that makes sense. My only question is how many platforms _don't_ Bruce> have syslog. If it is only NT and QNX, I think we can live with using Bruce> it by default if it exists. perhaps you could take some code from http://freshmeat.net/projects/cpslapi/ which implements a syslog-api that writes to NT's eventlog. i'd be glad to change the license if it is useful. jr -- ------------------------------------------------------------------------ Joel W. Reed 412-257-3881 --------------All the simple programs have been written.----------------
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, that makes sense. My only question is how many platforms _don't_
> have syslog. If it is only NT and QNX, I think we can live with using
> it by default if it exists.
There seems to be a certain amount of confusion here. The proposal at
hand was to make configure set up to *compile* the syslog support
whenever possible. Not to *use* syslog by default. Unless we change
the default postgresql.conf --- which I would be against --- we will
still log to stderr by default.
Given that, I'm not sure that Peter's argument about losing
functionality is right; the analogy to readline support isn't exact.
Perhaps what we should do is (a) always build syslog support if
possible, and (b) at runtime, complain if syslog logging is requested
but we don't have it available.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, that makes sense. My only question is how many platforms _don't_ > > have syslog. If it is only NT and QNX, I think we can live with using > > it by default if it exists. > > There seems to be a certain amount of confusion here. The proposal at > hand was to make configure set up to *compile* the syslog support > whenever possible. Not to *use* syslog by default. Unless we change > the default postgresql.conf --- which I would be against --- we will > still log to stderr by default. > > Given that, I'm not sure that Peter's argument about losing > functionality is right; the analogy to readline support isn't exact. > Perhaps what we should do is (a) always build syslog support if > possible, and (b) at runtime, complain if syslog logging is requested > but we don't have it available. Did we decide to compile in syslog support by default? I thought so. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, that makes sense. My only question is how many platforms _don't_ > > have syslog. If it is only NT and QNX, I think we can live with using > > it by default if it exists. > > There seems to be a certain amount of confusion here. The proposal at > hand was to make configure set up to *compile* the syslog support > whenever possible. Not to *use* syslog by default. Unless we change > the default postgresql.conf --- which I would be against --- we will > still log to stderr by default. > > Given that, I'm not sure that Peter's argument about losing > functionality is right; the analogy to readline support isn't exact. > Perhaps what we should do is (a) always build syslog support if > possible, and (b) at runtime, complain if syslog logging is requested > but we don't have it available. Is this idea dead for 7.2? Should I add it to the TODO list? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026