Thread: debug_level 0 does not stop debug messages
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 generate moreoutput, 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
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 generate
moreoutput, 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
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
>
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
Jon writes: > 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. The "interaction" is completely ad hoc, i.e., the code is free to write anything to the log and completely ignore the debug level. I agree that there should be a more systematic approach to what gets logged. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
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 >
> 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?
OK, I did a little research on this. It turns out that this code in
vacuum.c:
if (vacstmt->verbose)
MESSAGE_LEVEL = NOTICE;
else
MESSAGE_LEVEL = DEBUG;
controls whether the message comes out as a NOTICE or a DEBUG. My guess
is that you are doing a VACUUM VERBOSE, and those are coming out in the
server logs.
Guys, is this the proper way to handle this?
--
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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, I did a little research on this. It turns out that this code in
> vacuum.c:
> if (vacstmt->verbose)
> MESSAGE_LEVEL = NOTICE;
> else
> MESSAGE_LEVEL = DEBUG;
> controls whether the message comes out as a NOTICE or a DEBUG. My guess
> is that you are doing a VACUUM VERBOSE, and those are coming out in the
> server logs.
> Guys, is this the proper way to handle this?
It could probably be done better, but VACUUM has behaved like that for
quite a few years now. I don't see any need to change it until we have
a complete redesign of message handling in mind. Peter E. has muttered
about some ideas in that line...
regards, tom lane