On Tue, Oct 24, 2006 at 07:43:15AM +0100, Shane Wright wrote:
Anyway - not noticed any data loss yet and was hoping it would be such
that if all tables had been vacuumed recently (including system catalog
tables), that there would be no remaining rows that would appear to
have a future xid and
On Tue, Oct 24, 2006 at 11:06:01AM +0100, Shane Wright wrote:
If I was to abort this vacuum, given that all other tables are vacuumed
(including system catalog tables), what's the worst case scenario? -
given that more transactions are happening on the database
Only tables that havn't been
)
Many thanks for your help!
S
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: 24 October 2006 11:50
To: Shane Wright
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] recovery from xid wraparound
On Tue, Oct 24, 2006 at 11:06:01AM +0100, Shane Wright
2006 15:23
To: Shane Wright
Cc: Martijn van Oosterhout; pgsql-general@postgresql.org
Subject: Re: [GENERAL] recovery from xid wraparound
Shane Wright [EMAIL PROTECTED] writes:
Just make sure you've really covered *all* the system tables.
I've been under the impression system tables get done
Hi
I'm running 7.4 on RHAS 4, and I think I've had a transaction id
wraparound issue. Running the command below gives the suitably
worrying negative number:
emystery=# SELECT datname, age(datfrozenxid) FROM pg_database;
datname | age
--+-
[maindbname]
Shane Wright [EMAIL PROTECTED] 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
On Tue, Oct 24, 2006 at 03:47:52PM +0100, Shane Wright wrote:
Incidentally, how many passes of a table can vacuum make! Its currently
on its third trip through the 20Gb of indices, meaning another 7 hours
till completion [of this table]!.
Assume it only does three passes? (it chooses
Shane Wright [EMAIL PROTECTED] writes:
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?
reload is enough.
Basically if its just datfrozenxid that's not updated I can live with
delaying the
