Re: Index trouble with 8.3b4
От | Gregory Stark |
---|---|
Тема | Re: Index trouble with 8.3b4 |
Дата | |
Msg-id | 87sl17wya9.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Index trouble with 8.3b4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Index trouble with 8.3b4
Re: Index trouble with 8.3b4 |
Список | pgsql-hackers |
"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!
В списке pgsql-hackers по дате отправления: