Gregory Stark escribió:
> "Alvaro Herrera" <alvherre@commandprompt.com> writes:
>
> > Hmm, it looks like the race condition Heikki mentioned is the culprit.
> > We need a way to stop future analyzes from starting. Back to the
> > drawing board ...
>
> A crazy idea I just had -- what if you roll this into the deadlock check? So
> after waiting on the lock for 1s it wakes up, finds that the holder it's
> waiting on is an autovacuum process and cancels it instead of finding no
> deadlock.
Another crazy idea is to have some sort of "blacklist" of tables in
shared memory. Any autovacuum process would skip those tables.
My idea is that a would-be locker automatically puts the table in the
blacklist, then kill autovacs, then press on.
My idea is to accompany the relid with the Xid of the locker
transaction, so the worker checks whether the transaction is still
running, and removes the item from the blacklist if not.
(The only problem then is figuring out how large a black list to have,
and how to evict items when it is full and somebody else wants to
blacklist another table. For pg_dump it is more than enough to have
MaxBackends, since there is always at most one transaction, but I
wouldn't be surprised if I'm overlooking something.)
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.