Bruce Momjian writes:
> I never heard any discussion on whether this should be backpatched to
> 8.0.X. Should it?
I'm not inclined to throw it in at the last minute, as it's not been
through any testing and I'm not sure the behavior has really been agreed
on anyway. (The diff you cite starts fr
Bruce Momjian 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 th
Ron Mayer wrote:
> Bruce Momjian wrote:
> >
> > You didn't like server_min_messages = 'notify'?
>
> I merely don't have a feeling for how much additional stuff
> verbose would be putting in the log files.
You will probably see the creation of indexes and sequences, like this:
te
Bruce Momjian wrote:
You didn't like server_min_messages = 'notify'?
I merely don't have a feeling for how much additional stuff
verbose would be putting in the log files.
If it's a good practice for production systems to be logging
NOTIFY's I'm happy with the change.
My reasoning why I thought the
Ron Mayer wrote:
> Well, I was really hoping something would end up in the log file.
>
> The situation is that our clients - sometimes not that computer
> savvy - go perhaps a year without us being involved (unless
> the log monitoring scripts show something abnormal; or if the
> system breaks).
>
Well, I was really hoping something would end up in the log file.
The situation is that our clients - sometimes not that computer
savvy - go perhaps a year without us being involved (unless
the log monitoring scripts show something abnormal; or if the
system breaks).
The primary motivation for twea
I have applied your patch with minor modifications. Applied version
attached.
I think the "pages" message:
INFO: free space map: 44 relations, 28 pages stored; 704 total pages
used
DETAIL: FSM size: 1000 relations + 2 pages = 182 kB shared memory.
should remain D
On Sun, 27 Feb 2005, Simon Riggs wrote:
> On Fri, 2005-02-25 at 16:48 -0800, Ron Mayer wrote:
> > Getting closer?
> For me, yes. [...]
> The not-warnings seem a little wordy for me, but they happen when and
> how I would hope for.
>
> So, for me, it looks like a polish of final wording and commi
[ Previous version removed.]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
--
On Fri, 2005-02-25 at 16:48 -0800, Ron Mayer wrote:
> Getting closer?
For me, yes.
I agree with Bruce's comment on the use of the word "needed", and I
think your change reads better now.
The not-warnings seem a little wordy for me, but they happen when and
how I would hope for.
So, for me, it
On Fri, 25 Feb 2005, Bruce Momjian wrote:
> Tom Lane wrote:
> > Ron Mayer <[EMAIL PROTECTED]> writes:
> > > Should the relation overflow be a WARNING or a LOG? ...
> > I'd go for making them both LOG, I think. More consistent.
>
> Can we also update this wording:
>
> INFO: free space map: 52 r
Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > Should the relation overflow be a WARNING or a LOG? It sounds like
> > if you have that problem it's almost certainly a problem, right?
>
> I'd go for making them both LOG, I think. More consistent.
Can we also update this wording:
IN
On Thu, 24 Feb 2005, Tom Lane wrote:
> I'd go for making them both LOG, I think. More consistent.
Ok, here's another try :) With a couple more questions...
1. If I read Simon's email correctly, it implied that he wanted to see
the "free space map" message for a VACUUM even when VERBOSE
On Thu, 24 Feb 2005, Ron Mayer wrote:
> Should the relation overflow be a WARNING or a LOG? It sounds like
> if you have that problem it's almost certainly a problem, right?
And while I'm at it... what's the convention for INFOs vs LOGs?
The "checkpoint...too frequent" seemed similar, and is a L
Ron Mayer <[EMAIL PROTECTED]> writes:
> Should the relation overflow be a WARNING or a LOG? It sounds like
> if you have that problem it's almost certainly a problem, right?
I'd go for making them both LOG, I think. More consistent.
regards, tom lane
---
On Thu, 24 Feb 2005, Tom Lane wrote:
> I preferred Simon's idea of not trying to produce a warning for pages
> when we've detected relation overflow.
Sounds good. I'll make that update.
Should the relation overflow be a WARNING or a LOG? It sounds like
if you have that problem it's almost cert
Ron Mayer <[EMAIL PROTECTED]> writes:
> Would the updated patch below address most of the concerns?
I preferred Simon's idea of not trying to produce a warning for pages
when we've detected relation overflow.
Making it a LOG rather than WARNING does address the issue of being
too much in-your-fac
Thanks everyone for the feedback on my patch.
Objections I've heard (both online and in email) included:
* WARNING is too strong for possibly OK behavior
* It's similar to "checkpoints occuring too frequently...
consider increasing...checkpoint_segments" which
is a LOG
On Wed, 2005-02-23 at 19:31 -0500, Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > +if (needed > MaxFSMPages)
> > +ereport(WARNING,
> > +(errmsg("max_fsm_pages(%d) is smaller than total pages
> > needed(%.0f)",
> > + MaxFSMPages, needed)));
>
> An u
I find this tiny (9-line) patch useful to help my clients know
when FSM settings may need updating.
Some of the more frequently asked questions here are in regards to FSM
settings. One hint I've seen is to run "vacuum verbose;". At the end
of thousands of lines of INFO and DETAIL messages
Ron Mayer <[EMAIL PROTECTED]> writes:
> +if (needed > MaxFSMPages)
> +ereport(WARNING,
> +(errmsg("max_fsm_pages(%d) is smaller than total pages
> needed(%.0f)",
> + MaxFSMPages, needed)));
An unconditional WARNING seems a bit strong to me for a case that is no
Short summary:
I find this tiny (9-line) patch useful to help my clients know
when FSM settings may need updating.
Some of the more frequently asked questions here are in regards to FSM
settings. One hint I've seen is to run "vacuum verbose;". At the end
of thousands of lines of INFO and
22 matches
Mail list logo
