"Tom Lane" <[EMAIL PROTECTED]> writes: > It cannot be one of the first two, because those only block > for xacts that *already have* a conflicting lock. The problem must be > at the third wait step, which waits out all xacts that might conceivably > be interested in recently-dead tuples that are not in the index.
Ah, I had missed that point. > Now an unindexed dead tuple is not a problem from vacuum's point of > view, nor does ANALYZE care, so AFAICS there is no need for this step > to wait for autovacuum processes --- nor indeed for manual vacuums. > So we can avoid the deadlock if we just exclude those processes from > the list of ones to wait for. That's what I had in mind. > I suggest we extend GetCurrentVirtualXIDs() with an additional > parameter includeVacuums, and have it skip vacuum procs if that's > set. (Hmm, maybe a more flexible approach is to make the parameter > a bitmask, and ignore any procs for which param & vacuumFlags is > not zero.) > > Comments? Only that the restrictions on what VACUUM is allowed to do seem the piling up. We may have to write up a separate document explaining what specialized set of rules VACUUM operates under. Also, ANALYZE was included in the latest security changes. Is there some way that ANALYZE could trigger some user-defined function being invoked which could in turn run some SQL using this index? I suppose a very strange expression index where the expression involved a recursive SQL query back to the same table (presumably being careful to avoid an infinite loop) could be possible. I am hoping our other things which ignore VACUUM such as the globalxmin calculation are careful not to ignore VACUUM ANALYZE processes? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
