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: (view raw, whole thread or download thread mbox)
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

I am hoping our other things which ignore VACUUM such as the globalxmin
calculation are careful not to ignore VACUUM ANALYZE processes?

  Gregory Stark
  Ask me about EnterpriseDB's 24x7 Postgres support!

In response to


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-2017 The PostgreSQL Global Development Group