Aw :(
Its at the default of 8Mb. The table contains 220 million rows and 6 indices. It has a few deleted rows...
If I change vacuum_mem I'll need to at least 'pg_ctl reload' - will it apply straightaway with the next vacuum query or
doesit need a full restart?
Does vacuum_mem need shared memory? (i.e. is it subject to the OS's limit) - have looked in the docs and googled but
can'tsee detail on this
If I have managed to vacuum all the catalog tables, and my script has ensured all user tables other than this one have
beenvacuumed, then... will the first pass of vacuum on this have set the xid to FrozenXID for all rows - i.e. is the
tablesafe?
What's the relative safety of restarting this vacuum with a bigger vacuum_mem, say at the end of the week when traffic
isquieter?
Basically if its just datfrozenxid that's not updated I can live with delaying the vacuum a few days. But if things
aremore serious then obviously I can't wait.
Is it safe to say that if the catalog tables are ok and an individual tables has been vacuumed then its data is safe?
S
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 24 October 2006 15:52
To: Shane Wright
Cc: pgsql-general@postgresql.org; Martijn van Oosterhout
Subject: Re: [GENERAL] recovery from xid wraparound
"Shane Wright" <shane.wright@edigitalresearch.com> writes:
> Incidentally, how many passes of a table can vacuum make!
Lots, especially if the table hasn't been vacuumed in a long time... Perhaps you should be using a higher
maintenance_work_mem?(Um, in 7.4 make that vacuum_mem.) Larger work memory translates directly to fewer passes over
theindexes.
regards, tom lane
