Re: debug_level 0 does not stop debug messages - Mailing list pgsql-bugs

From Jon
Subject Re: debug_level 0 does not stop debug messages
Date
Msg-id Pine.SOL.4.02.10105031219200.21003-100000@azure.engin.umich.edu
Whole thread Raw
In response to Re: debug_level 0 does not stop debug messages  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: debug_level 0 does not stop debug messages  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-bugs
Sure,
   I have about 70 tables, each vacuum prints out something like this per
table.  You'll notice it prints stuff for each index also.

postgres[23034]: [566] DEBUG:  --Relation test--
postgres[23034]: [567-1] DEBUG:  Pages 1: Changed 1, reaped 1, Empty 0,
New 0; Tup 3: Vac 1, Keep/VTL 0/0, Crash 0, UnUsed 14, MinLen 67, MaxLen
67;
postgres[23034]: [567-2]  Re-using: Free/Avail. Space 7896/0;
EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec.
postgres[23034]: [568] DEBUG:  Index test_pkey: Pages 2;
Tuples 3: Deleted 1. CPU -1.99s/0.00u sec.

Also, on a side note, I read a post to the list about 2 weeks ago about
you writing a performance tuning document and putting it up on the
website. Did this happen and I miss it, or is it still in the works?

Thanks,
   Jon Poland


On Thu, 3 May 2001, Bruce Momjian wrote:

>
> Can you give me a few sample lines that you are seeing in the log?
>
> > Hi,
> >     I'm not using pg_ctl, I'm using postmaster directly.  So, in my case I
> > tried passing "-d0" to it, but it had no effect.  Command line:
> >
> > postmaster -i -d0 -D /var/pgsql/data -c syslog=2
> >
> > Any ideas?  I could patch the code to remove the excessive elog's in the
> > vacuum command, but I'd rather understand how elog interacts with the
> > global DebugLvl variable.
> >
> > JP
> >
> > On Tue, 1 May 2001, Justin Clift wrote:
> > > Hi,
> > >
> > > This might sound weird, but try "
> > >
> > > pg_ctl start -o '-d0'
> > >
> > > Include any other options you need of course too.  The point is not
> > > having a space between the -d and the 0.
> > >
> > > This fixes things for me when I have the default startup options
> > > different, but need logging off for a while.
> > >
> > > Regards and best wishes,
> > >
> > > Justin Clift
> > >
> > > pgsql-bugs@postgresql.org wrote:
> > > >
> > > > JP (smasher@bikerider.com) reports a bug with a severity of 2
> > > > The lower the number the more severe it is.
> > > >
> > > > Short Description
> > > > debug_level 0 does not stop debug messages
> > > >
> > > > Long Description
> > > > I'm trying to silence the annoying output generated by vacuum.  I've
> > > > tried both command line options (-d 0, -S (with syslog enabled)) and
> > > > postgresql.conf (debug_level = 0, silent_mode = 1).  Setting debug
> > > > level to 0 should silence these messages, but still let errors through.  Setting debug level higher seems to
generatemore output, which is great.  just be nice if the vacuum output were at level 3 or 
> > > > greater.
> > > >
> > > > Platform: OpenBSD 2.8 (i386)
> > > > PG Version: 7.1
> > > >
> > > > Sample Code
> > > >
> > > > No file was uploaded with this report
> > > >
> > > > ---------------------------(end of broadcast)---------------------------
> > > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> > >
> > > --
> > > "My grandfather once told me that there are two kinds of people: those
> > > who work and those who take the credit. He told me to try to be in the
> > > first group; there was less competition there."
> > >      - Indira Gandhi
> > >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
>
> --
>   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, Pennsylvania 19026
>

pgsql-bugs by date:

Previous
From: "J.R. Onyschak"
Date:
Subject: Re: PostgreSQL bug in SELECT DISTINCT
Next
From: "J.R. Onyschak"
Date:
Subject: Re: PostgreSQL bug in SELECT DISTINCT