Обсуждение: 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.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