Thread: 7.0 RPMS and syslog problem.
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@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.usenameas "Owner" FROM pg_class c, pg_user u WHERE c.relowner = u.usesysid AND c.relkind = 'r' AND not exists
(select1 from pg_views where viewname = c.relname) AND c.relname !~ '^pg_' UNION SELECT c.relname as "Name",
'table'::textas "Type", NULL as "Owner" FROM pg_class c WHERE c.relkind = 'r' AND not exists (select 1 from pg_views
whereviewname = 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_classc, pg_user u WHERE c.relowner = u.usesysid AND relkind in ('S') AND c.relname !~ '^pg_' UNION SELECT
c.relnameas "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@gkg.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@gkg.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@gkg.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