From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
Subject: | Re: Index trouble with 8.3b4 |
Date: | 2008-01-09 02:03:26 |
Message-ID: | 87sl17wya9.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
"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!
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-01-09 02:31:17 | Re: Experiences with extensibility |
Previous Message | Alvaro Herrera | 2008-01-09 01:42:29 | Re: Experiences with extensibility |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-09 02:08:00 | Problem with CVS HEAD's handling of mergejoins |
Previous Message | Tom Lane | 2008-01-08 23:47:47 | Re: Index trouble with 8.3b4 |