From: Alvaro Herrera <alvherre@commandprompt.com>
To: Marinos Yannikos <mjy@geizhals.at>
Cc: pgsql-performance@postgresql.org
Subject: Re: VACUUM FULL needed sometimes to prevent transaction ID wraparound?
Date: Tue, 22 Aug 2006 15:19:53 -0400
Message-ID: <20060822191952.GG25475@alvh.no-ip.org> (raw)
In-Reply-To: <44EB48A9.7030704@geizhals.at>
References: <44EB48A9.7030704@geizhals.at>
Marinos Yannikos wrote:
> Hello,
>
> we're looking into the reason why we are getting warnings about
> transaction ID wraparound despite a daily "vaccumdb -qaz". Someone is
> claiming that VACUUM without FULL cannot reassign XIDs properly when
> max_fsm_pages was set too low (it says so here too, but this is rather
> old: http://www.varlena.com/GeneralBits/Tidbits/perf.html#maxfsmp). Is
> this true, or do we have a different issue here? We're using 8.1.3 with
> a database generated on 8.1.3 (i.e. not migrated from 7.x or anything
> like that).
It's not true. Having shortage of FSM entries will make you lose space,
but it will be able to recycle Xids anyway.
I guess your problem is that you're not vacuuming all databases for some
reason. I'd advise to lose the -q and make sure you're not redirecting
to somewhere you can't read the log; the read the log and make sure
everything is going fine.
What's the warning anyway? Does it say that wraparound point is
nearing, or does it merely say that it is on Xid <some number here> and
you don't know how far that number actually is?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: alvherre@commandprompt.com, mjy@geizhals.at
Subject: Re: VACUUM FULL needed sometimes to prevent transaction ID wraparound?
In-Reply-To: <20060822191952.GG25475@alvh.no-ip.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox