Re: Double entries in log for page slots in beta3

One exceedingly minor logging issue I just noticed in looking at the log
from a beta3.

[2006-11-28 06:37:08.152 CST] 14775 <postgres dtr [local]> NOTICE:
number of page slots needed (2296208) exceeds max_fsm_pages (1000000)
[2006-11-28 06:37:08.152 CST] 14775 <postgres dtr [local]> HINT:
Consider increasing the configuration parameter "max_fsm_pages" to a
value over 2296208.
[2006-11-28 06:37:08.152 CST] 14775 <postgres dtr [local]> LOG: number
of page slots needed (2296208) exceeds max_fsm_pages (1000000)
[2006-11-28 06:37:08.152 CST] 14775 <postgres dtr [local]> HINT:
Consider increasing the configuration parameter "max_fsm_pages" to a
value over 2296208.

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> One exceedingly minor logging issue I just noticed in looking at the log
> from a beta3.

Yeah, this is someone's idea of a feature:

CheckFreeSpaceMapStatistics(NOTICE, numRels, needed);
/* Print to server logs too because is deals with a config variable. */
CheckFreeSpaceMapStatistics(LOG, numRels, needed);

I thought it was a crock when it was put in, but lost the argument.

regards, tom lane

Tom Lane wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> One exceedingly minor logging issue I just noticed in looking at the log
>> from a beta3.
>
> Yeah, this is someone's idea of a feature:
>
> CheckFreeSpaceMapStatistics(NOTICE, numRels, needed);
> /* Print to server logs too because is deals with a config variable. */
> CheckFreeSpaceMapStatistics(LOG, numRels, needed);
>
> I thought it was a crock when it was put in, but lost the argument.

IIRC, I was the one wanting it to get into server logs at
default log settings; since I found it most useful at catching
the too low FSM settings in a regularly scheduled vacuum;
and if I recall, the previous output about FSM space never
ended up in log files unless you set the level to something
quite verbose.

If there's a better way for me to be managing this, let me know
and I'll happily withdraw my requests that the message be spewed
twice.

Actually there's something else I wanted to bring up regarding
this "feature" - now that autovacuum's around; the only reason I
still have a scheduled database-wide-vacuum is for this FSM message.

If there's a way of getting the info without doing the vacuum,
(i.e. was a pg_* view created that lets me see it?) I'll be even
happier to withdraw that request.

Ron M

>>> On Tue, Nov 28, 2006 at 3:37 PM, in message
<456CAC0E(dot)3090409(at)cheapcomplexdevices(dot)com>, Ron Mayer
<rm_pg(at)cheapcomplexdevices(dot)com> wrote:
> Tom Lane wrote:
>> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>>> One exceedingly minor logging issue I just noticed in looking at
the log
>>> from a beta3.
>>
>> Yeah, this is someone's idea of a feature:
>>
>> CheckFreeSpaceMapStatistics(NOTICE, numRels, needed);
>> /* Print to server logs too because is deals with a config
variable. */
>> CheckFreeSpaceMapStatistics(LOG, numRels, needed);
>>
>> I thought it was a crock when it was put in, but lost the argument.
>
> If there's a better way for me to be managing this, let me know
> and I'll happily withdraw my requests that the message be spewed
> twice.

I've generally been capturing the output of my nightly VACUUM ANALYZE
VERBOSE run, and looking for this information at the end of that file.

> the only reason I
> still have a scheduled database- wide- vacuum is for this FSM
message.

Isn't it necessary to do this periodically to prevent transaction ID
wraparound?

-Kevin

Kevin Grittner wrote:
> > If there's a better way for me to be managing this, let me know
> > and I'll happily withdraw my requests that the message be spewed
> > twice.
>
> I've generally been capturing the output of my nightly VACUUM ANALYZE
> VERBOSE run, and looking for this information at the end of that file.
>
> > the only reason I
> > still have a scheduled database- wide- vacuum is for this FSM
> message.
>
> Isn't it necessary to do this periodically to prevent transaction ID
> wraparound?

autovacuum takes care of that too, at least in 8.2 and I think 8.1.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Nov 28, 2006, at 1:37 PM, Ron Mayer wrote:
> If there's a way of getting the info without doing the vacuum,
> (i.e. was a pg_* view created that lets me see it?) I'll be even
> happier to withdraw that request.

AFAIK there isn't, and it would be useful to have. But FSM info alone
doesn't tell you the whole picture; you'd have to know that vacuum
couldn't find space in the FSM to store some pages. So perhaps what's
really needed is information about how many pages in a relation
couldn't be put into the FSM the last time a vacuum was run.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim Nasby <decibel(at)decibel(dot)org> writes:
> AFAIK there isn't, and it would be useful to have. But FSM info alone
> doesn't tell you the whole picture; you'd have to know that vacuum
> couldn't find space in the FSM to store some pages. So perhaps what's
> really needed is information about how many pages in a relation
> couldn't be put into the FSM the last time a vacuum was run.

Curiously enough, that's exactly what the FSM stats tell you now.

regards, tom lane

On Tue, Dec 05, 2006 at 11:04:17AM -0500, Tom Lane wrote:
> Jim Nasby <decibel(at)decibel(dot)org> writes:
> > AFAIK there isn't, and it would be useful to have. But FSM info alone
> > doesn't tell you the whole picture; you'd have to know that vacuum
> > couldn't find space in the FSM to store some pages. So perhaps what's
> > really needed is information about how many pages in a relation
> > couldn't be put into the FSM the last time a vacuum was run.
>
> Curiously enough, that's exactly what the FSM stats tell you now.

But only at the end of a database-wide vacuum verbose, right? Or did I
miss something?

It would be useful to be able to get that info in a system running
autovac (or anything else that means not normally vacuuming the whole
database).
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> On Tue, Dec 05, 2006 at 11:04:17AM -0500, Tom Lane wrote:
>> Curiously enough, that's exactly what the FSM stats tell you now.

> But only at the end of a database-wide vacuum verbose, right?

True. It was done that way to provide some minimal assurance that the
numbers would be somewhat up-to-date --- obviously in a cluster with
multiple active databases this isn't good enough, but it's what we were
able to do conveniently.

I believe that you can get the equivalent info from
contrib/pg_freespacemap/ as of 8.2.

regards, tom lane