Re: debug_level 0 does not stop debug messages
От | Bruce Momjian |
---|---|
Тема | Re: debug_level 0 does not stop debug messages |
Дата | |
Msg-id | 200105081828.f48ISUe21060@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: debug_level 0 does not stop debug messages (Jon <polandj@engin.umich.edu>) |
Ответы |
Re: debug_level 0 does not stop debug messages
|
Список | 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? 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
В списке pgsql-bugs по дате отправления: