Bruce Momjian pgman@candle.pha.pa.us writes:
These new messages:
NOTICE: max_fsm_relations(1000) equals the number of relations checked
HINT: You have = 44 relations.
Consider increasing the configuration parameter max_fsm_relations.
NOTICE: the number of
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:
test=
Greg Stark wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
These new messages:
NOTICE: max_fsm_relations(1000) equals the number of relations checked
HINT: You have = 44 relations.
Consider increasing the configuration parameter max_fsm_relations.
Bruce Momjian pgman@candle.pha.pa.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_
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
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).
The
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
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
[ 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.
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 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 commit.
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 relations, 61
On Wed, 23 Feb 2005, Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
+if (needed MaxFSMPages)... ereport(WARNING, ...
An unconditional WARNING seems a bit strong to me for a case that is not
necessarily wrong.
How about a HINT, not unlike the checkpoints are occurring too
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
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 unconditional
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
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-face
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
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, 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 LOG.
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 is
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:
INFO:
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 not
24 matches
Mail list logo
