On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh gurj...@singh.im wrote:
On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Gregory Stark wrote:
I'm having trouble following what's
On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh gurj...@singh.im wrote:
On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Gregory Stark wrote:
I'm having trouble following what's
On Tue, Jul 7, 2015 at 11:20 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh gurj...@singh.im wrote:
log_min_messages acts as a single gate for everything headed for the
On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh gurj...@singh.im wrote:
On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Gregory Stark wrote:
I'm having trouble following what's going on with autovacuum and I'm
finding
the existing logging insufficient. In
On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera alvhe...@commandprompt.com
wrote:
Gregory Stark wrote:
I'm having trouble following what's going on with autovacuum and I'm
finding
the existing logging insufficient. In particular that it's only logging
vacuum
runs *after* the vacuum
Gregory Stark wrote:
I'm having trouble following what's going on with autovacuum and I'm finding
the existing logging insufficient. In particular that it's only logging vacuum
runs *after* the vacuum finishes makes it hard to see what vacuums are running
at any given time. Also, I want to
I'm having trouble following what's going on with autovacuum and I'm finding
the existing logging insufficient. In particular that it's only logging vacuum
runs *after* the vacuum finishes makes it hard to see what vacuums are running
at any given time. Also, I want to see what is making
Gregory Stark [EMAIL PROTECTED] writes:
I would also suggest raising the level of the DEBUG2 message indicating why
tables were chosen or not. At least to DEBUG1 if not to INFO.
It's not acceptable for autovacuum to be cluttering the log by default.
regards, tom lane
Gregory Stark wrote:
I'm having trouble following what's going on with autovacuum and I'm finding
the existing logging insufficient. In particular that it's only logging vacuum
runs *after* the vacuum finishes makes it hard to see what vacuums are running
at any given time. Also, I want to see
Le mardi 07 août 2007, Tom Lane a écrit :
Gregory Stark [EMAIL PROTECTED] writes:
log_autovacuum_jobs - output every time a vacuum or analyze *starts*
[...]
I would also suggest raising the level of the DEBUG2 message indicating
why tables were chosen or not. At least to DEBUG1 if not to
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I would also suggest raising the level of the DEBUG2 message indicating why
tables were chosen or not. At least to DEBUG1 if not to INFO.
It's not acceptable for autovacuum to be cluttering the log by default.
Well
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dimitri Fontaine wrote:
Le mardi 07 août 2007, Tom Lane a écrit :
Gregory Stark [EMAIL PROTECTED] writes:
log_autovacuum_jobs - output every time a vacuum or analyze *starts*
[...]
I would also suggest raising the level of the DEBUG2 message
Joshua D. Drake [EMAIL PROTECTED] writes:
With 8.3 having autovacuum on by default, we really should be logging at
a mininum:
autovacuum start
autovacuum working (what am I working on but not what I am doing,
meaning we don't need tuple information etc..)
autovacuum stop
Yes, by default
Tom Lane wrote:
Yes, by default or at least at no level higher than INFO.
No, NOT by default. Our users have made it perfectly clear that they
don't want the logs cluttered with high-volume information about
non-error normal workings of the system. Every time we have caused
the system to
Peter Eisentraut [EMAIL PROTECTED] writes:
But INFO is not shown by default.
INFO is mostly a hack to try to emulate VACUUM VERBOSE's ancient
behavior before we redesigned the elog levels. It's intended for
controlling messages that should go to a client because the client
asked for them, and
On 8/7/07, Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
But INFO is not shown by default.
INFO is mostly a hack to try to emulate VACUUM VERBOSE's ancient
behavior before we redesigned the elog levels. It's intended for
controlling messages that should go
On Tue, Aug 07, 2007 at 11:59:03AM -0700, Andrew Hammond wrote:
On 8/7/07, Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
But INFO is not shown by default.
INFO is mostly a hack to try to emulate VACUUM VERBOSE's ancient
behavior before we redesigned the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Decibel! wrote:
On Tue, Aug 07, 2007 at 11:59:03AM -0700, Andrew Hammond wrote:
On 8/7/07, Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
But INFO is not shown by default.
INFO is mostly a hack to try to emulate
On Tue, 7 Aug 2007, Decibel! wrote:
Is logging really the answer for that? ISTM it'd be better to provide
statistics info so that you could monitor autovacuum activity with
things like cricket, SNMP, etc.
There are two sides to this. One is that it's difficult to right now to
tell when your
19 matches
Mail list logo
