Re: transaction timeout

> 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