Double entries in log for page slots in beta3

"Kevin Grittner" <Kevin.Grittner@wicourts.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.Grittner@wicourts.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.3090409@cheapcomplexdevices.com>, Ron Mayer
<rm_pg@cheapcomplexdevices.com> wrote:

Tom Lane wrote:

"Kevin Grittner" <Kevin.Grittner@wicourts.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@momjian.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@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim Nasby <decibel@decibel.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@decibel.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@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

"Jim C. Nasby" <jim@nasby.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