Rob Nagler <nagler@bivio.biz> writes:
> I've read some posts that says vacuum doesn't lock, but my experience
> today indicates the opposite. It seemed that "vacuum full analyze"
> was locked waiting and so were other postmaster processes.
vacuum full does require exclusive lock, plain vacuum does not.
> It
> appeared to be deadlock, because all were in "WAITING" state according
> to ps. I let this go for about a 1/2 hour, and then killed the vacuum
> at which point all other processes completed normally.
It's considerably more likely that the vacuum was waiting for an open
client transaction (that had a read or write lock on some table) to
finish than that there was an undetected deadlock. I suggest looking at
your client code. Also, in 7.3 or later you could look at the pg_locks
view to work out exactly who has the lock that's blocking vacuum.
> Another issue seems to be performance. A reindex on some indexes is
> taking 12 minutes or so. Vacuum seems to be slow, too. Way longer
> than the time it takes to reimport the entire database (30 mins).
vacuum full is indeed slow. That's why we do not recommend it as a
routine maintenance procedure. The better approach is to do plain
vacuums often enough that you don't need vacuum full. In pre-7.4
releases you might need periodic reindexes too, depending on whether
your usage patterns tickle the index-bloat problem. But it is easily
demonstrable that reindexing is cheaper than rebuilding the database.
> In summary, I suspect that it is better from a UI perspective to bring
> down the app on Sat at 3 a.m and reimport with a fixed time period
> than to live through reindexing/vacuuming which may deadlock. Am I
> missing something?
Almost certainly, though you've not provided enough detail to determine
what.
regards, tom lane