"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
> delayin
On Tue, Oct 24, 2006 at 04:18:09PM +0100, Shane Wright wrote:
> 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?
You can control it per session I think. So you can start psql and type:
# set va
OTECTED]
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" <[EMAIL PROTECTED]> writes:
> Incidentally, how many passes of a table can vacuum make!
Lots,
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 choose
"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
d
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 based on the table
> continuing to be up
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: 24 October 2006 10:24
To: Shane Wright
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] recovery from xid wraparound
On Tue, Oct 24, 2006 at 07:43:15AM +0100, Shane Wright wrote:
> Anyway -
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]
tober 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 bee
"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 first, then
> user(me)-created tables after -
No, there's no such guarantee. A database-wide vacuum just does the
tables in the orde
Martijn van Oosterhout writes:
> A VACUUM will recover any data that slipped beyond the horizon less
> than 1 billion transactions ago, which I think covers you completely.
> The only issue is that unique indexes may be confused because new
> conflicting data may have been inserted while the old d
ese aren't coming up from
other databases)
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
O
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
To: Shane Wright
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] recovery from xid wraparound
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 (inc
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
HiI'm running 7.4 on RHAS 4, and I think I've
had a transaction idwraparound issue in a stats database we have.
Running the command below gives the suitablyworrying negative
number:[dbname]=# SELECT datname, age(datfrozenxid) FROM
pg_database; datname |
age--+-
16 matches
Mail list logo
