On Montag, 25. Januar 2010 Kevin Grittner wrote:
> Have a look at reltoastrelid:
Hmm.. select * from pg_class; doesnt give anything containing 1910021
that I had in the log. So what? A temporary table? But that shouldn't be
bloated nor auto-vacuumed, right?
--
mit freundlichen Grüssen,
Michae
Michael Monnerie wrote:
> such a bloat can't happen in a day.
That is evidence that you may have a problem with some long-running
transaction which stays open for days, possibly "idle in
transaction". Bloat will accumulate, without any vacuum being able
to prevent it or recover from it, until
On Montag, 25. Januar 2010 Kevin Grittner wrote:
> Any chance you had or have long-running transactions. We once had
> very low free space in a big database which suddenly ballooned. It
> turned out an application programmer had left a connection in "idle
> in transaction" state for a few days.
>
Michael Monnerie wrote:
> So, as there was that one relation that was bloatet - how could it
> be? Autovaccuum, nightly vacuum analyze, weekly cluster - and
> still a heavy bloated toast* something. I must do something wrong.
Any chance you had or have long-running transactions. We once had
v
On Montag, 25. Januar 2010 Kevin Grittner wrote:
> Michael Monnerie wrote:
> > why did postgres suddenly decide to remove the old cruft suddenly?
>
> Have you read through this yet?:
>
> http://www.postgresql.org/docs/8.3/interactive/runtime-config-resourc
> e.html#RUNTIME-CONFIG-RESOURCE-FSM
Y
Michael Monnerie wrote:
> why did postgres suddenly decide to remove the old cruft suddenly?
Have you read through this yet?:
http://www.postgresql.org/docs/8.3/interactive/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-FSM
> Autovacuum is on, the nightly backups do an extra "vacuum
First of all run the VACUUM FULL ANALYZE and that should hopefully help you
get rid of this problem without changing the max_fsm_pages. Other then this
I will recommend you to have the autovacuuming process in place for proper
database maintenance.
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com
Dextra - Gustavo Bartz Guedes wrote:
> Is the parameter max_fsm_pages cluster-wide or per-database?
cluster-wide.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Roa
"Jouneau Luc" <[EMAIL PROTECTED]> writes:
> INFO: Pages 11944: Changed 11944, Empty 0; Tup 32: Vac 1931936, Keep 0, Un=
> Used 0.
> Total CPU 1.57s/1.90u sec elapsed 42.01 sec.
> It seems that FSM traced all of my deletes since it mentions removes in 864=
> 1+3303=3D11944 pages (>1 wh
On Fri, 2003-01-03 at 09:44, Robert Treat wrote:
> relations determines
> the total number of "objects" the database is willing to pay attention
> to. The default is set to 100, which means if you have more than 100
> tables/indicies in your database, vacuum might ignore some tables that
> are bei
On Thu, 2003-01-02 at 19:15, HT Levine wrote:
> see my answers below:
> "Robert Treat" <[EMAIL PROTECTED]> wrote in message
> 1041547656.32015.38.camel@camel">news:1041547656.32015.38.camel@camel...
> > >
> >
> > Tables with no deletions or updates won't benefit from vacuuming so
> > there's no re
see my answers below:
"Robert Treat" <[EMAIL PROTECTED]> wrote in message
1041547656.32015.38.camel@camel">news:1041547656.32015.38.camel@camel...
> Haven't been following this list too closely over the holiday break,
> hopefully this can still be of some use to you.
>
> On Mon, 2002-12-30 at 13:12
Haven't been following this list too closely over the holiday break,
hopefully this can still be of some use to you.
On Mon, 2002-12-30 at 13:12, HT Levine wrote:
> "Tom Lane" <[EMAIL PROTECTED]> wrote in message
> >
> > 1. You don't need to take down the DB to do vacuuming.
>
>
> when I tried t
Thanks for the response. See my responses below. I'll crank it up to 1
million fsm pages. and report back when we finish with the results I
know they aren't as interesting with 7.2.3 as they would be with 7.3 but it
may help someone else.
"Tom Lane" <[EMAIL PROTECTED]> wrote in message
[EM
"HT" <[EMAIL PROTECTED]> writes:
> We have quite large production Postgres 7.2 DB which is out of control in
> terms of disk consumption. We made it thru the holiday shopping season,
> but it isn't over yet. We have taken the DB down once for a vacuum analyze
> but only vacuum'd 2 large table
15 matches
Mail list logo
