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 по дате отправления: