On Mon, Jun 04, 2007 at 07:34:13AM -0700, Ron St-Pierre wrote:
> >VACUUM FULL _does not_ mean "vacuum everything"!
> What do you mean by this?
Sorry, I was trying to prevent you doing a VACUUM FULL you didn't
want (but another message said you actually intended a vacuum full).
Several people ha
On Mon, Jun 04, 2007 at 07:34:13AM -0700, Ron St-Pierre wrote:
> What do you mean by this? I wanted to do both a VACUUM ANALYZE and a
> VACUUM FULL, so ran VACUUM FULL ANALYZE. Is there something odd about
> VACUUM FULL, other than locking the table it's working on?
It tends to bloat indexes. A
Andrew Sullivan wrote:
On Fri, Jun 01, 2007 at 01:27:14PM -0700, Ron St-Pierre wrote:
imp=# select age(datfrozenxid) from pg_database where datname = 'imp';
age
1571381411
(1 row)
Time to start VACUUM FULL ANALYZE over the weekend.
I guess this comes too late, b
On Fri, Jun 01, 2007 at 01:27:14PM -0700, Ron St-Pierre wrote:
> imp=# select age(datfrozenxid) from pg_database where datname = 'imp';
> age
>
> 1571381411
> (1 row)
>
> Time to start VACUUM FULL ANALYZE over the weekend.
I guess this comes too late, but you don't need VAC
Alvaro Herrera wrote:
FYI, in 8.2 and up the Xid wraparound problem is considered on a table
by table basis, which means that only the tables that have not been
vacuumed recently need to be vacuumed. The need for database wide
vacuuming is gone.
That's good.
Time to start VACUUM FULL ANAL
Ron St-Pierre wrote:
> I stopped using autovacuum months ago because of similar problems
> (version 8.1.4). Because we do some major inserts and updates about four
> times a day, there were a few tables that I didn't want autovacuumed.
> Even after I turned autovacuum off for these tables it sti
I stopped using autovacuum months ago because of similar problems
(version 8.1.4). Because we do some major inserts and updates about four
times a day, there were a few tables that I didn't want autovacuumed.
Even after I turned autovacuum off for these tables it still tried to
vacuum them whil
> select age(datfrozenxid) from pg_database where datname = 'your database'
>
> 2 billions and you are screwed. Autovacuum starts panicking way before
> that, to have enough slack.
dbname=# select age(datfrozenxid) from pg_database where datname = 'dbname';
age
1648762992
(1 ro
Csaba Nagy wrote:
> On Fri, 2007-06-01 at 17:40, Alvaro Herrera wrote:
> > Huh, why do you say that it doesn't need any vacuuming?
>
> This table is only inserted and rarely deleted, so other than the XID
> wraparound vacuuming it is not critical. Of course it will need vacuum
> finally, but it ca
On Fri, 2007-06-01 at 17:40, Alvaro Herrera wrote:
> Huh, why do you say that it doesn't need any vacuuming?
This table is only inserted and rarely deleted, so other than the XID
wraparound vacuuming it is not critical. Of course it will need vacuum
finally, but it can survive months without it -
Csaba Nagy wrote:
> [snip]
> > You don't need to reindex, just update.
>
> I was pretty sure I've seen the error reported and the fix too, the
> thing is relatively harmless except the vacuum troubles. And considering
> that the table itself does not need vacuuming, it would be even more
> harmles
[snip]
> You don't need to reindex, just update.
I was pretty sure I've seen the error reported and the fix too, the
thing is relatively harmless except the vacuum troubles. And considering
that the table itself does not need vacuuming, it would be even more
harmless if it wouldn't block other stu
Erik Jones wrote:
> On Jun 1, 2007, at 9:19 AM, Csaba Nagy wrote:
>
> >On Fri, 2007-06-01 at 15:58, Alvaro Herrera wrote:
> >>Try reindexing the table; that should make the problem go away.
> >>Also,
> >>update to the latest of the 8.1 branch ASAP.
> >
> >Reindexing won't work, it would mean ho
> How would reindexing a table imply hours of downtime?
Simply, all meaningful activities on this system will sooner or later
insert into this table :-)
So given that we use a connection pool we end up pretty soon with all
connections waiting for an insert on this table, and at that point
nothing
On Jun 1, 2007, at 9:19 AM, Csaba Nagy wrote:
On Fri, 2007-06-01 at 15:58, Alvaro Herrera wrote:
Try reindexing the table; that should make the problem go away.
Also,
update to the latest of the 8.1 branch ASAP.
Reindexing won't work, it would mean hours of downtime. I plan to move
the DB
On Fri, 2007-06-01 at 15:58, Alvaro Herrera wrote:
> Try reindexing the table; that should make the problem go away. Also,
> update to the latest of the 8.1 branch ASAP.
Reindexing won't work, it would mean hours of downtime. I plan to move
the DB to 8.2 via slony in ~2-3 weeks, that should take
Csaba Nagy wrote:
> Trouble: the autovacuum daemon is still taking that table and vacuums
> it... how do I know ? So:
>
> select l.pid,c.relname from pg_locks l, pg_class c where l.pid not in
> (select distinct procpid from pg_stat_activity) and l.relation=c.oid and
> c.relkind='r';
>
> pid |
> If that table has a TOAST table you might need to mark the toast table
> as disabled too. Or maybe it's forcing a vacuum because it's worried
> about XID wraparound?
OK, that might be the case, as I guess there are tables which were not
successfully vacuumed in the last few months (DB wide vacu
Csaba Nagy <[EMAIL PROTECTED]> writes:
> System: postgres 8.1.3p, not a released version but a CVS checkout
> somewhere after 8.1.3 was released.
Updating to 8.1.6 or later would fix your "failed to re-find parent key"
problem.
> Trouble: the autovacuum daemon is still taking that table and vacuu
Hi all,
System: postgres 8.1.3p, not a released version but a CVS checkout
somewhere after 8.1.3 was released.
I have a table (quite big one, 2 columns, 2166381 DB relpages, 364447136
reltuples as reported by pg_class) which is mostly inserted into, very
rarely deleted from.
I also have a primar
20 matches
Mail list logo
