Re: BUG #4730: Vacuum full verbose analyze "deadlock" - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #4730: Vacuum full verbose analyze "deadlock"
Date
Msg-id 49C9F643.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to BUG #4730: Vacuum full verbose analyze "deadlock"  ("Wayne Conrad" <wconrad@yagni.com>)
Responses Re: BUG #4730: Vacuum full verbose analyze "deadlock"
List pgsql-bugs
>>> "Wayne Conrad" <wconrad@yagni.com> wrote:

> "VACUUM FULL ANALYZE VERBOSE" on a "deadlocks"

> "VACUUM VERBOSE ANALYZE" (without the "FULL") does not

You do realize that FULL should not be part of normal maintenance,
right?  It is sometimes useful to recover from table bloat when normal
maintenance fails.  Although it is almost always much slower than
CLUSTER, it has the advantage of not requiring disk space for a second
copy of the table, but it requires a REINDEX afterward to correct the
index bloat it causes.  If you are doing a good job of normal
maintenance, you never, ever should be running VACUUM FULL.

None of the above means you haven't found a problem worth looking at
-- I'm not trying to comment on that; but unless you are in the middle
of recovery from abnormal bloat, you may be able to dodge the problem
by correcting your maintenance practices.

-Kevin

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #4731: compile with -fast fails on ld: duplicate symbol _PGP_S2K_TYPE in pgp.o and pgp-mpi-openssl.o
Next
From: Tom Lane
Date:
Subject: Re: BUG #4731: compile with -fast fails on ld: duplicate symbol _PGP_S2K_TYPE in pgp.o and pgp-mpi-openssl.o