Re: Index trouble with 8.3b4

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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!