"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > Because we wouldn't want multiple ANALYZEs running on the same table, > changing the lock back to an AccessShareLock doesn't sound like a > solution.
It flat will not work. We used to do it that way, and it didn't (search for "tuple concurrently updated" in the archives). > However, what are the thoughts around creating another, > more-specific lock? Perhaps something like ShareUpdateAnalysisLock? The general overhead involved in a whole new lock type is high enough that I would resist taking this path. (It's certainly a lot more than adding an entry to one enum someplace --- offhand I can name docs and grammar as important issues. And no you don't get to have a hidden lock type that no one can see.) Also, as Alvaro points out, it's far from clear that concurrent VACUUM and ANALYZE is as safe as you think --- they both want to write the same fields in pg_class. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers