"Tom Lane" <tgl@sss.pgh.pa.us> 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!