On Tue, Jul 7, 2015 at 11:20 AM, Sawada Masahiko
wrote:
> On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila
> wrote:
> > On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh wrote:
> >> log_min_messages acts as a single gate for everything headed for the
> >> server logs; controls for per-background process
On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila wrote:
> On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh wrote:
>>
>> On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera
>> wrote:
>>>
>>> Gregory Stark wrote:
>>> >
>>> > I'm having trouble following what's going on with autovacuum and I'm
>>> > finding
>>
On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila wrote:
> On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh wrote:
>>
>> On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera
>> wrote:
>>>
>>> Gregory Stark wrote:
>>> >
>>> > I'm having trouble following what's going on with autovacuum and I'm
>>> > finding
>>
On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh 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
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 finishes makes it h
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
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
-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
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
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
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
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 syst
"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
-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 m
"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 def
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 n
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 wh
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
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 autovacuu
19 matches
Mail list logo
