Re: [GENERAL] A way to let Vacuum warn if FSM settings are

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [GENERAL] A way to let Vacuum warn if FSM settings are
Date: 2005-03-14 20:15:58
Message-ID: 200503142015.j2EKFwg28867@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches

Simon Riggs wrote:
> On Mon, 2005-03-14 at 01:40 -0500, Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Ron Mayer wrote:
> > >> My reasoning why I thought the log file was more useful was
> > >> that only an admin with access to the log files could really
> > >> do anything about the message anyway.
> >
> > > The log file is useful, but I think showing the VACUUM user is _more_
> > > useful than the log file.
> >
> > I think that reasoning is fundamentally unsound, because (a) a lot of
> > people already do vacuuming via a cron job or autovacuum, and (b)
> > autovacuum is definitely the wave of the future. So it's foolish
> > to design this messaging around the assumption that there will be
> > a human attentive to the on-line output from VACUUM. We should be
> > ensuring that the message gets into the postmaster log --- whether
> > it gets sent to the client is secondary.
>
> Personally, I prefer the postmaster log as the place for this.
>
> However, whilst vacuum exists as a separate command, there will be an
> argument to return a message back to the person running it; we cannot
> assume that people would be inattentive.
>
> Possibly the deciding factor should be whether autovacuum makes it fully
> into becoming a special backend anytime soon, since in that case only
> the log would remain as an option for reporting this message, in that
> case.
>
> Can we have both?

Sure. It is very easy and in fact looks even cleaner than the original
code because now the optional stuff is in its own function.

Patch attached and applied.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Attachment Content-Type Size
unknown_filename text/plain 2.5 KB

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Robert Treat 2005-03-14 20:51:41 Re: PostgreSQL training
Previous Message Marco Colombo 2005-03-14 19:14:42 Re: plpython function problem workaround

Browse pgsql-patches by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-03-15 01:57:56 Improvement to charset docs
Previous Message Tom Lane 2005-03-14 19:41:01 Re: [pgsql-hackers-win32] snprintf causes regression tests to fail