debug_level 0 does not stop debug messages

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 more 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

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

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 generate more 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:

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