On 10/14/2014 03:59 PM, MauMau wrote:
BTW, in LWLockWaitForVar(), the first line of the following code fragment is
not necessary, because lwWaitLink is set to head immediately. I think it
would be good to eliminate as much unnecessary code as possible from the
spinlock section.
proc->lwWaitL
From: "MauMau"
Thank you very much. I didn't anticipate such a difficult complicated
cause. The user agreed to try the patch tonight. I'll report back the
result as soon as I got it from him.
The test ran successfully without hang for 24 hours. It was run with your
patch + the following:
From: "Heikki Linnakangas"
Committed this.
Thank you very much. I didn't anticipate such a difficult complicated
cause. The user agreed to try the patch tonight. I'll report back the
result as soon as I got it from him.
BTW, in LWLockWaitForVar(), the first line of the following code fr
On 10/13/2014 06:57 PM, Heikki Linnakangas wrote:
Hmm, we could set releaseOK in LWLockWaitForVar(), though, when it
(re-)queues the backend. That would be less invasive, for sure
(attached). I like this better.
Committed this.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 10/13/2014 06:26 PM, Andres Freund wrote:
On 2014-10-13 17:56:10 +0300, Heikki Linnakangas wrote:
So the gist of the problem is that LWLockRelease doesn't wake up
LW_WAIT_UNTIL_FREE waiters, when releaseOK == false. It should, because a
LW_WAIT_UNTIL FREE waiter is now free to run if the vari
On 2014-10-13 17:56:10 +0300, Heikki Linnakangas wrote:
> So the gist of the problem is that LWLockRelease doesn't wake up
> LW_WAIT_UNTIL_FREE waiters, when releaseOK == false. It should, because a
> LW_WAIT_UNTIL FREE waiter is now free to run if the variable has changed in
> value, and it won't
On Mon, Oct 13, 2014 at 10:56 AM, Heikki Linnakangas
wrote:
> I noticed another potential bug: LWLockAcquireCommon doesn't use a volatile
> pointer when it sets the value of the protected variable:
>
>> /* If there's a variable associated with this lock, initialize it
>> */
>> if (
On 10/13/2014 10:47 AM, Heikki Linnakangas wrote:
On 10/10/2014 05:08 PM, MauMau wrote:
From: "Craig Ringer"
It sounds like they've produced a test case, so they should be able to
with a bit of luck.
Or even better, send you the test case.
I asked the user about this. It sounds like the re
On 10/10/2014 05:08 PM, MauMau wrote:
> From: "Craig Ringer"
>> It sounds like they've produced a test case, so they should be able to
>> with a bit of luck.
>>
>> Or even better, send you the test case.
>
> I asked the user about this. It sounds like the relevant test case consists
> of many sc
On 2014-10-10 23:08:34 +0900, MauMau wrote:
> From: "Craig Ringer"
> >It sounds like they've produced a test case, so they should be able to
> >with a bit of luck.
> >
> >Or even better, send you the test case.
>
> I asked the user about this. It sounds like the relevant test case consists
> of
From: "Craig Ringer"
It sounds like they've produced a test case, so they should be able to
with a bit of luck.
Or even better, send you the test case.
I asked the user about this. It sounds like the relevant test case consists
of many scripts. He explained to me that the simplified test s
On 10/10/2014 04:16 AM, MauMau wrote:
> From: "Craig Ringer"
>> It'd be interesting and useful to run this test on a debug build of
>> PostgreSQL, i.e. one compiled against the debug version of the C library
>> and with full debuginfo not just minimal .pdb.
>
> Although I'm not sure the user can
From: "Andres Freund"
What precisely do you mean with "Intel64"? 64bit x86 or Itanium?
64-bit x86, i.e. x86-64.
Also, what's the precise workload? Can you reproduce the problem?
IIUC, each client inserts 1000 records into one table, then repeats updating
all those records. I'll ask him
From: "Craig Ringer"
It'd be interesting and useful to run this test on a debug build of
PostgreSQL, i.e. one compiled against the debug version of the C library
and with full debuginfo not just minimal .pdb.
Although I'm not sure the user can do this now, I'll ask him anyway.
How were the s
On 2014-10-09 22:47:48 +0900, MauMau wrote:
> Hello,
>
> One user reported a hang problem with 9.4 beta2 on Windows. The PostgreSQL
> is 64-bit version. I couldn't find the cause, but want to solve the
> problem. Could you help with this?
>
> I heard that the user had run 16 concurrent psql se
On 10/09/2014 09:47 PM, MauMau wrote:
>
> I heard that the user had run 16 concurrent psql sessions which executes
> INSERT and UPDATE statements, which is a write-intensive stress test.
> He encountered the hang phenomenon twice, one of which occured several
> hours after the start of the test,
16 matches
Mail list logo
