Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Ants Aasma <ants(at)cybertec(dot)at>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Date: 2012-06-04 15:38:24
Message-ID: CAHyXU0xDLz47vxjj-9sxzvm9qcz5d78VN90JSQGwb3i9RvYV8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 4, 2012 at 10:17 AM, Merlin Moncure <mmoncure(at)gmail(dot)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?

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2012-06-04 15:38:39 Re: [RFC] Interface of Row Level Security
Previous Message Fujii Masao 2012-06-04 15:20:14 Re: Updated version of pg_receivexlog