Re: recovery from xid wraparound

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 does it 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't see 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 been vacuumed, then... will the first pass of vacuum on this have set the xid to FrozenXID for all rows - i.e. is the table safe?

What's the relative safety of restarting this vacuum with a bigger vacuum_mem, say at the end of the week when traffic is quieter?

Basically if its just datfrozenxid that's not updated I can live with delaying the vacuum a few days. But if things are more 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(at)sss(dot)pgh(dot)pa(dot)us]
Sent: 24 October 2006 15:52
To: Shane Wright
Cc: pgsql-general(at)postgresql(dot)org; Martijn van Oosterhout
Subject: Re: [GENERAL] recovery from xid wraparound

"Shane Wright" <shane(dot)wright(at)edigitalresearch(dot)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 the indexes.

regards, tom lane