> Sure. Like this: > > Client A accesses table T, and "hangs." > Client B attempts to get an ACCESS EXCLUSIVE lock on > table T in > preparation for VACUUM FULL. > Client C connects to the database and waits for > client B to get and > release his lock on table T. > Client D connects to the database and waits for > client B to get and > release his lock on table T. > Client E connects to the database and waits for > client B to get and > release his lock on table T. > etc... oh! my! gawd! Finally a clear explanation that makes perfect sense. Now why did it take so long? So all I need to do is take out the FULL? Is regular VACUUM sufficient? How often do we need FULL? (I know it's a stupid question without providing some more context, but how can I estimate it?) I suppose the ultimate solution would be a wrapper script that works as follows: check if there are any waiting/idle in transaction processes if such processes exist, do a regular VACUUM and send out a warning email otherwise, do VACUUM FULL. I like this solution a lot more than getting support calls on weekends. Out of curiousity, how is lock acquisition implemented in postgresql? All the processes have to go through some sort of queue, so that locks are granted in FIFO order, as you described. Just trying to understand it better. thanks a lot, Eugene __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
