Re: condition variables - Mailing list pgsql-hackers

From Robert Haas
Subject Re: condition variables
Date
Msg-id CA+Tgmob6zbs4vK7NAZUS_aeLe5RqcN1L-ERHS0YWBECHR7gb_w@mail.gmail.com
Whole thread Raw
In response to Re: condition variables  (Peter Geoghegan <pg@heroku.com>)
Responses Re: condition variables
List pgsql-hackers
On Tue, Sep 13, 2016 at 10:55 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Another approach to the problem is to use a latch wait loop.  That
>> almost works.  Interrupts can be serviced, and you can recheck shared
>> memory to see whether the condition for proceeding is satisfied after
>> each iteration of the loop.  There's only one problem: when you do
>> something that might cause the condition to be satisfied for other
>> waiting backends, you need to set their latch - but you don't have an
>> easy way to know exactly which processes are waiting, so how do you
>> call SetLatch?  I originally thought of adding a function like
>> SetAllLatches(ParallelContext *) and maybe that can work, but then I
>> had what I think is a better idea, which is to introduce a notion of
>> condition variables.
>
> I don't see a CF entry for this. Are you planning to work on this
> again soon, Robert?
>
> I have an eye on this patch due to my work on parallel CREATE INDEX.
> It would be nice to have some rough idea of when you intend to commit
> this.

I basically figured I would commit it when and if it became clear that
it'd get good use in some other patch which was on the road to being
committed.  I don't think it needs much work, just the assurance that
it will get some use.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: sequences and pg_upgrade
Next
From: Tom Lane
Date:
Subject: Re: Surprising behaviour of \set AUTOCOMMIT ON