Ron Snyder <snyder@roguewave.com> writes:
> I've noticed similar behavior, and have tracked it down to the
> pg_largeobject table. pg_largeobject is using about 50 Gigs of disk space
> in my currently running server (7.2.1), but going through a dump-n-restore
> cycle always ends up freeing up some disk.
What's your turnover rate for updating or deleting large objects?
I'm guessing that you have the FSM parameters (in postgresql.conf) set
too small to allow the system to keep track of all the free space in
pg_largeobject. Ideally, VACUUM logs all the space it frees into
the FSM, and this space is then reused by subsequent inserts/updates,
and you run out of it right about the time of the next VACUUM run.
But if the FSM is too small then some space "leaks" in each cycle
and you have continuing growth of the table.
There is some code in CVS tip to help you determine whether FSM is large
enough or not, but in 7.2 or 7.3 you gotta work it out for yourself :-(
regards, tom lane
