Skip site navigation (1) Skip section navigation (2)

Re: Index trouble with 8.3b4

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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!

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-01-09 02:08:00
Subject: Problem with CVS HEAD's handling of mergejoins
Previous:From: Tom LaneDate: 2008-01-08 23:47:47
Subject: Re: Index trouble with 8.3b4

pgsql-general by date

Next:From: Gregory StarkDate: 2008-01-09 02:31:17
Subject: Re: Experiences with extensibility
Previous:From: Alvaro HerreraDate: 2008-01-09 01:42:29
Subject: Re: Experiences with extensibility

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group