Re: 7.0 RPMS and syslog problem. (more)

Hi.

I've installed the v7.0 postgresql RPMS from ftp.postgresql.org. I configured
my syslog to catch the local0 facility and log it to /var/log/pgsql with this
entry in /etc/syslog.conf:

local0.* /var/log/pgsql

This catches just about everything. However, if I fire up "psql template1" and
issue the command "\d", the following is broadcast to all tty's on the machine:

Message from syslogd(at)galaxy at Wed May 17 09:20:12 2000 ...
galaxy

My guess is that something is not logging to the correct facility. Has anyone
else seen this / found a work around for this?

my pg_options file contains:
verbose=1
query=4
syslog=2

Mike

Upon further investigation, I found that when the hostname is broadcast to everyone, the following also appears in /var/log/messages:

May 17 09:28:11 galaxy
May 17 09:28:11 galaxy syslogd: Cannot glue message parts together
May 17 09:28:11 galaxy 135>May 17 09:28:11 postgres[18087]: query: SELECT c.relname as "Name", 'table'::text as "Type", u.usename as "Owner" FROM pg_class c, pg_user u WHERE c.relowner = u.usesysid AND c.relkind = 'r' AND not exists (select 1 from pg_views where viewname = c.relname) AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", 'table'::text as "Type", NULL as "Owner" FROM pg_class c WHERE c.relkind = 'r' AND not exists (select 1 from pg_views where viewname = c.relname) AND not exists (select 1 from pg_user where usesysid = c.relowner) AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", 'view'::text as "Type", u.usename as "Owner" FROM pg_class c, pg_user u WHERE c.relowner = u.usesysid AND c.relkind = 'r' AND exists (select 1 from pg_views where viewname = c.relname) AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", 'view'::text as "Type", NULL as "Owner" FROM pg_class c WHERE c.relkind = 'r' AND exists (select 1 from pg_views whe!
re viewname = c.relname) AND not exists (select 1 fro
May 17 09:28:11 galaxy m pg_user where usesysid = c.relowner) AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", (CASE WHEN relkind = 'S' THEN 'sequence'::text ELSE 'index'::text END) as "Type", u.usename as "Owner" FROM pg_class c, pg_user u WHERE c.relowner = u.usesysid AND relkind in ('S') AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name", (CASE WHEN relkind = 'S' THEN 'sequence'::text ELSE 'index'::text END) as "Type", NULL as "Owner" FROM pg_class c WHERE not exists (select 1 from pg_user where usesysid = c.relowner) AND relkind in ('S') AND c.relname !~ '^pg_' ORDER BY "Name"

So the problem seems to stem from the "Cannot glue message parts together"

The hostname is being broadcast to with the level of "emerg" because if I
remove:

*.emerg *

from my syslog.conf file, I dont see the console message getting broadcast
anymore.

If anyone else has seen this or has any ideas, please let me know :).

Mike

Michael Schout <mschout(at)gkg(dot)net> writes:
> Upon further investigation, I found that when the hostname is broadcast to everyone, the following also appears in /var/log/messages:
> May 17 09:28:11 galaxy
> May 17 09:28:11 galaxy syslogd: Cannot glue message parts together

Hmm. We were just discussing this a few weeks ago, when someone
suggested making the syslog option be the default and I wanted to
know if it was really robust enough for that. Seems it's not.
On at least some platforms, syslog can't cope with log messages
exceeding a few hundred characters. Postgres 7.0 is quite capable
of putting out log messages in the megabyte range, if you have debug
logging turned on --- just shove a sufficiently long query at it.

So I'm afraid the answer is that syslog and verbose logging won't
play together, at least not on your platform. Sorry.

We really need a better logging answer...

regards, tom lane

Tom Lane wrote:

> Michael Schout <mschout(at)gkg(dot)net> writes:
> > Upon further investigation, I found that when the hostname is broadcast to everyone, the following also appears in /var/log/messages:
> > May 17 09:28:11 galaxy
> > May 17 09:28:11 galaxy syslogd: Cannot glue message parts together

> Hmm. We were just discussing this a few weeks ago, when someone
> suggested making the syslog option be the default and I wanted to
> know if it was really robust enough for that. Seems it's not.

> So I'm afraid the answer is that syslog and verbose logging won't
> play together, at least not on your platform. Sorry.

> We really need a better logging answer...

Splitting the logging message out to syslog in tprintf() (or its
replacement) would work, if we knew the syslog gluing buffer maxlen. A
'packetized' logging system of this sort might work....

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Wed, May 17, 2000 at 11:59:15AM -0400, Tom Lane wrote:
> Michael Schout <mschout(at)gkg(dot)net> writes:
>
> Hmm. We were just discussing this a few weeks ago, when someone
> suggested making the syslog option be the default and I wanted to
> know if it was really robust enough for that. Seems it's not.

Perhaps the maintainer of the binary RPMS on ftp.postgresql.org
could rebuild with syslog logging turned off by default?

Mike

Michael Schout wrote:
> On Wed, May 17, 2000 at 11:59:15AM -0400, Tom Lane wrote:
> > Hmm. We were just discussing this a few weeks ago, when someone
> > suggested making the syslog option be the default and I wanted to
> > know if it was really robust enough for that. Seems it's not.

> Perhaps the maintainer of the binary RPMS on ftp.postgresql.org
> could rebuild with syslog logging turned off by default?

Set the pg_options -- ie, set syslog to 0, or set query to 0, if you
don't need query logging. There's no need to recompile, as the runtime
option sets things properly. I would prefer to not disable syslog when
it is working fine for those who have shorter queries. I will, however,
change the default pg_options with syslog set to 0 -- same effect, but
it still allows those with less difficult query-length requirements to
use the feature -- with the caveat that too long a query with query
logging on will crash out syslog.

So, I have two notices to add to the ramifordistat page, and to the
README.rpm..... I won't build a -2 release as yet, until we get the
actual query length of overflow (volunteers?) so that it can be
documented.

If you want to completely disable syslog on your own RPMS, feel free to
download the src.rpm, edit rpm-pgsql-7.0.patch to remove the USE_SYSLOG
define, and rebuild with rpm -ba. Then install the resulting RPMs. If
you wouldn't mind, change the release number so that no one gets
confused.

HTH

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11