Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
| От | Ants Aasma |
|---|---|
| Тема | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
| Дата | |
| Msg-id | CA+CSw_sS+T-wma9hQHBE7EGFx=OaX0jbuy81QZ1xDvRGFCeJyQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile (Merlin Moncure <mmoncure@gmail.com>) |
| Ответы |
Re: 9.2beta1, parallel queries, ReleasePredicateLocks,
CheckForSerializableConflictIn in the oprofile
|
| Список | pgsql-hackers |
On Mon, Jun 4, 2012 at 6:38 PM, Merlin Moncure <mmoncure@gmail.com> wrote: > On Mon, Jun 4, 2012 at 10:17 AM, Merlin Moncure <mmoncure@gmail.com> wrote: >> What happens (in the very unlikely, but possible case?) if another >> backend races to the buffer you've pointed at with 'victim'? It looks >> like multiple backends share the clock sweep now, but don't you need >> to need an extra test to ensure it's still a candidate victim buffer? > > Actually, I don't think you do: the existing check on refcount is > probably good enough. Hm, why did you get rid of > BufferStrategyControl.lastFreeBuffer? It was dead code as far as I could tell. That change isn't actually relevant for this patch because free-list management is still protected by a lock (except the initial unlocked test that is doublechecked under lock) and so doesn't need any adjustment. Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de
В списке pgsql-hackers по дате отправления: