Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile - Mailing list pgsql-hackers

From Ants Aasma
Subject Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Date
Msg-id CA+CSw_sS+T-wma9hQHBE7EGFx=OaX0jbuy81QZ1xDvRGFCeJyQ@mail.gmail.com
Whole thread Raw
In response to Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
List 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 by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [RFC] Interface of Row Level Security
Next
From: Ants Aasma
Date:
Subject: Re: Updated version of pg_receivexlog