The "wa" means waiting on IO. Vacuum is a very IO intensive
process. You can use tools like vmstat and iostat to see how much
disk IO is occurring. Also, sar is very helpful for trending these
values over time.
-- Will Reese http://blog.rezra.com
On May 9, 2006, at 5:19
ng space because some developer's code fails to commit or
rollback a transaction. Just be careful you aren't killing off
processes that are actually doing work. :)
-- Will Reese http://blog.rezra.com
On May 2, 2006, at 7:01 PM, Devrim GUNDUZ wrote:
Hi,
On Tue, 2006-05-02 at 17:
ly affects rebuild performance and write performance) and
you get better fault tolerance (up to 3 disks can fail in a 6 disk
RAID 10 and you can still be online, with RAID 5 you can only lose 1
drive). All of this comes with a higher cost (more drives and higher
end cards).
-- Will
not cause as many locking issues with FKs on 8.1 as it did
in 7.4 (which is why one of the RI triggers was removed in the first
place).
Will Reese -- http://blog.rezra.com
On Apr 26, 2006, at 6:43 PM, Stef T wrote:
Hey there Will,
I would assume that, perhaps, jst perhaps, the FK
ity in 8.1 will allow us to re-add our
constraints and not suffer from the locking issues we had in
postgresql 7.4.
Will Reese -- http://blog.rezra.com
On Apr 23, 2006, at 10:32 PM, Tom Lane wrote:
Will Reese <[EMAIL PROTECTED]> writes:
... Both servers have identical postgresql.c
t
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."B" x WHERE
"A_ID" = $1 FOR SHARE OF x"
It looks to me like the "SELECT ... FOR SHARE" functionality in 8.1
is the culprit. Has anyone else run into this issue?
ERROR: canceling statement due to user request
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."B" x WHERE
"A_ID" = $1 FOR SHARE OF x"
It looks to me like the "SELECT ... FOR SHARE" functionality in 8.1
is the
