Re: Heap truncation without AccessExclusiveLock (9.4)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Heap truncation without AccessExclusiveLock (9.4)
Дата
Msg-id 17573.1368724542@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Heap truncation without AccessExclusiveLock (9.4)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Heap truncation without AccessExclusiveLock (9.4)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
>> 2. If you don't find an entry for your target rel in the cache, aren't
>> you still going to have to do an lseek?

> Don't think of it as a cache.  The caching happens inside each
> backend's relcache; the shared memory structure is just a tool to
> force those caches to be revalidated when necessary.

Hmm.  Now I see: it's not a cache, it's a Bloom filter.  The failure
mode I was thinking of is inapplicable, but there's a different one:
you have to be absolutely positive that *any* operation that extends the
file will update the relevant filter entry.  Still, I guess that we're
already assuming that any such op will take the relation's extension
lock, so it should be easy enough to find all the places to fix.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Heap truncation without AccessExclusiveLock (9.4)
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Patch proposal: query result history in psql