Thread

1. 7.0 RPMS and syslog problem.

   Michael J Schout <mschout@gkg.net> — 2000-05-17T14:26:05Z

   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
   
   

2. Re: 7.0 RPMS and syslog problem. (more)

   Michael J Schout <mschout@gkg.net> — 2000-05-17T14:44:53Z

   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
   
   

3. Re: 7.0 RPMS and syslog problem. (more)

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-17T15:59:15Z

   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
   
   

4. Re: 7.0 RPMS and syslog problem. (more)

   Lamar Owen <lamar.owen@wgcr.org> — 2000-05-17T16:55:59Z

   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
   
   

5. Re: 7.0 RPMS and syslog problem. (more)

   Michael J Schout <mschout@gkg.net> — 2000-05-17T22:52:14Z

   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
   
   

6. Re: 7.0 RPMS and syslog problem. (more)

   Lamar Owen <lamar.owen@wgcr.org> — 2000-05-18T03:37:10Z

   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