On Mon, Nov 21, 2016 at 11:48 PM, Thomas Munro
wrote:
> Here's a version that works that way, though it allows you to call
> ConditionVariablePrepareToSleep *optionally* before you enter your
> loop, in case you expect to have to wait and would rather avoid the
> extra loop. Maybe there isn't muc
At Tue, 22 Nov 2016 17:48:07 +1300, Thomas Munro
wrote in
> On Tue, Nov 22, 2016 at 3:05 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello,
> >
> > At Mon, 21 Nov 2016 15:57:47 -0500, Robert Haas
> > wrote in
> >
> >> On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas wrote:
> >> > So, in my
> >> > impl
On Tue, Nov 22, 2016 at 3:05 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Mon, 21 Nov 2016 15:57:47 -0500, Robert Haas wrote
> in
>> On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas wrote:
>> > So, in my
>> > implementation, a condition variable wait loop looks like this:
>> >
>> > for (;;)
>> > {
Hello,
At Mon, 21 Nov 2016 15:57:47 -0500, Robert Haas wrote
in
> On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas wrote:
> > So, in my
> > implementation, a condition variable wait loop looks like this:
> >
> > for (;;)
> > {
> > ConditionVariablePrepareToSleep(cv);
> > if (condition for
On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas wrote:
> So, in my
> implementation, a condition variable wait loop looks like this:
>
> for (;;)
> {
> ConditionVariablePrepareToSleep(cv);
> if (condition for which we are waiting is satisfied)
> break;
> ConditionVariableSleep();
On Mon, Nov 21, 2016 at 7:10 AM, Thomas Munro
wrote:
>> I wonder if we shouldn't try to create the invariant that when the CV
>> mutex is not help, the state of cvSleeping has to be true if we're in
>> the proclist and false if we're not. So ConditionVariableSignal()
>> would clear the flag befor
On Fri, Oct 28, 2016 at 9:38 AM, Robert Haas wrote:
> On Tue, Oct 4, 2016 at 3:12 PM, Thomas Munro
> wrote:
>> On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro
>> wrote:
>>> Please find attached a -v2 of your patch which includes suggestions
>>> 1-3 above.
>>
>> Here's a rebased patch. ConditionVa
On Tue, Oct 4, 2016 at 3:12 PM, Thomas Munro
wrote:
> On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro
> wrote:
>> Please find attached a -v2 of your patch which includes suggestions
>> 1-3 above.
>
> Here's a rebased patch. ConditionVariableSleep now takes
> wait_event_info. Anyone using this in
On Tue, Oct 4, 2016 at 12:12 PM, Thomas Munro
wrote:
> Here's a rebased patch. ConditionVariableSleep now takes
> wait_event_info. Anyone using this in patches for core probably needs
> to add enumerators to the WaitEventXXX enums in pgstat.h to describe
> their wait points.
I think that there
On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro
wrote:
> Please find attached a -v2 of your patch which includes suggestions
> 1-3 above.
Here's a rebased patch. ConditionVariableSleep now takes
wait_event_info. Anyone using this in patches for core probably needs
to add enumerators to the WaitEv
Maybe I can leave it up to you to determine if that applies in the context
of my parallel create index patch. You are the obvious candidate to review
that patch anyway, of course.
--
Peter Geoghegan
On Tue, Sep 13, 2016 at 10:55 PM, Peter Geoghegan wrote:
> On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas 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
On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas 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. Th
On Tue, Sep 6, 2016 at 5:29 PM, Robert Haas wrote:
> On Mon, Sep 5, 2016 at 3:17 PM, Amit Kapila wrote:
>> On Mon, Aug 15, 2016 at 10:35 PM, Robert Haas wrote:
> Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
I poked at this a bit... OK, a lot... and hav
On Mon, Sep 5, 2016 at 3:17 PM, Amit Kapila wrote:
> On Mon, Aug 15, 2016 at 10:35 PM, Robert Haas wrote:
Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
>>>
>>> I poked at this a bit... OK, a lot... and have some feedback:
>>>
>>> 1. As above, we need to clear cv
On Mon, Aug 15, 2016 at 10:35 PM, Robert Haas wrote:
>>> Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
>>
>> I poked at this a bit... OK, a lot... and have some feedback:
>>
>> 1. As above, we need to clear cvSleeping before setting the latch.
>
> Right, OK.
>
I have
On 2016-08-11 21:27:45 -0400, Robert Haas wrote:
> On Thu, Aug 11, 2016 at 6:37 PM, Peter Geoghegan wrote:
> > I notice that you acquire a spinlock within the implementation of
> > condition variables. Is it worth any effort to consolidate the number
> > of spinlock acquisitions? In other words, m
On Mon, Aug 15, 2016 at 1:58 AM, Thomas Munro
wrote:
> On Sun, Aug 14, 2016 at 9:04 AM, Thomas Munro
> wrote:
>> On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
>>> [condition-variable-v1.patch]
>>
>> Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
>
> I poked at t
On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro
wrote:
> Also, I have attached a v2->v3 diff ...
Ugh. I meant a v1->v2 diff.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
On Sun, Aug 14, 2016 at 9:04 AM, Thomas Munro
wrote:
> On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
>> [condition-variable-v1.patch]
>
> Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
I poked at this a bit... OK, a lot... and have some feedback:
1. As above,
On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
> [condition-variable-v1.patch]
Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Thu, Aug 11, 2016 at 8:44 PM, Thomas Munro
wrote:
> In contrast, this proposal leaves it up to client code to get that
> right, similarly to the way you need to do things in a certain order
> when waiting for state changes with latches. You could say that it's
> more error prone: I think there
On Thu, Aug 11, 2016 at 6:37 PM, Peter Geoghegan wrote:
> I notice that you acquire a spinlock within the implementation of
> condition variables. Is it worth any effort to consolidate the number
> of spinlock acquisitions? In other words, maybe the most common idioms
> should be baked into the Co
On Thu, Aug 11, 2016 at 6:12 PM, Tom Lane wrote:
>> But if we replace the io_in_progress locks with
>> condition variables, then that doesn't happen any more. Nobody is
>> "holding" the condition variable, so it doesn't get "released" when
>> the process doing I/O aborts. Instead, they just keep
On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
> https://en.wikipedia.org/wiki/Monitor_(synchronization)#Condition_variables_2
>
> Basically, a condition variable has three operations: you can wait for
> the condition variable; you can signal the condition variable to wake
> up one waiter; or
On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas 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. Th
Robert Haas writes:
> I had what I think is a better idea, which is to introduce a notion of
> condition variables.
Interesting proposal.
> ... Using condition variables here seems to
> have a couple of advantages. First, it means that a backend waiting
> for buffer I/O to complete is interrupt
Hi,
Some of my EnterpriseDB colleagues and I have been working on various
parallel query projects, all of which have been previously disclosed
here:
https://wiki.postgresql.org/wiki/EnterpriseDB_database_server_roadmap
One issue we've encountered is that it's not very easy for one process
in a g
28 matches
Mail list logo
