Re: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

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(at)michvhf(dot)com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 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(at)gmx(dot)net http://funkturm.homeip.net/~peter

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(at)unl(dot)edu(dot)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(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

On Sep 12, pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026