James Robinson wrote:
> How does 8.2 [ or 8.3 ] deal with table locking in the face of no-
> argument 'cluster' command? Does it lock all tables it is going to visit
> 'up front', or does it collect locks slowly as it visits tables? If it
> only locks a new table before it visits it, does it unlock it once it is
> done?
It runs on one transaction per table: the lock on each table is grabbed
just before working on it, and released as soon as it is done. Of
course, for each table there are locks on the indexes and toast table
and index involved, too.
> Finally, is it a candidate for deadlock detection and unrolling just as
> other locking ops are [ I can imagine one wouldn't want to deadlock-kill
> the clustering backend, but the backend it contends with might be fodder
> assuming its a lesser command ].
Hmm, I think it could deadlock if someone is holding a lock on, say, an
index, and then attempts to lock the table. I don't recall the exact
details.
> We just some observed an undetected deadlock-ish issue, and the juciest
> aspect was that a db-wide cluster was running.
Can you provide more details? pg_locks, pg_stat_activity, the deadlock
message?
(Hmm, it would be helpful if the deadlock checker were to save the
pg_locks contents and perhaps pg_stat_activity in a file, whenever a
deadlock is detected.)
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.