On Tue, Sep 13, 2016 at 10:55 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
