On Sun, Jul 26, 2015 at 11:36 AM, Andres Freund and...@anarazel.de wrote:
On 2015-07-07 13:25:24 +0200, Andres Freund wrote:
So, it's starting to look good. Not exactly allowing for a lot of
confidence yet, but still:
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anolebr=HEAD
On 2015-07-07 13:25:24 +0200, Andres Freund wrote:
So, it's starting to look good. Not exactly allowing for a lot of
confidence yet, but still:
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anolebr=HEAD
Since there have not been any relevant failures since, I'm going to
remove
On Tue, Jul 7, 2015 at 7:25 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-30 11:35:56 +0200, Andres Freund wrote:
On 2015-06-29 22:58:05 -0400, Tom Lane wrote:
So personally, I would be inclined to put back the volatile qualifier,
independently of any fooling around with
On 2015-06-30 11:35:56 +0200, Andres Freund wrote:
On 2015-06-29 22:58:05 -0400, Tom Lane wrote:
So personally, I would be inclined to put back the volatile qualifier,
independently of any fooling around with _Asm_double_magic_xyzzy
calls.
I'm not sure. I think the reliance on an explicit
On 2015-06-29 12:11:08 +0200, Andres Freund wrote:
On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
#define S_UNLOCK(lock) \
do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
Robert, how did you choose that? Isn't _Asm_sched_fence just a compiler
barrier? Shouldn't this be a
On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
#define S_UNLOCK(lock)\
do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
Robert, how did you choose that? Isn't _Asm_sched_fence just a compiler
barrier? Shouldn't this be a _Asm_mf()?
which immediately raises the question of why
On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
#define S_UNLOCK(lock)\
do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
Robert, how did you choose that? Isn't _Asm_sched_fence just a compiler
barrier?
On 2015-06-29 22:45:49 -0400, Robert Haas wrote:
On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
#define S_UNLOCK(lock)\
do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
Robert, how did you choose
On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
#define S_UNLOCK(lock)\
do {
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund and...@anarazel.de wrote:
You removed a volatile at the same time, and volatile on IA64 has
acquire/release semantics.
Can you explain what you mean by volatile having acquire/release
semantics? I
On Mon, Jun 29, 2015 at 10:53 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-29 22:45:49 -0400, Robert Haas wrote:
On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund
On Sun, Jun 28, 2015 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd hoped that commit 1b468a131bd260c9041484f78b8580c7f232d580 would
resolve this, but nope, anole is still getting occasional stuck spinlocks:
Robert Haas robertmh...@gmail.com writes:
That sucks. It was easy to see that the old fallback barrier
implementation wasn't re-entrant, but this one should be. And now
that I look at it again, doesn't the failure message indicate that's
not the problem anyway?
! PANIC: stuck spinlock
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Alvaro Herrera wrote:
Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Uh. I'm pretty sure there were some back when that patch went in. And
there definitely used to be a couple earlier. I guess itanium really is
dying (mixed bad: It's
On Sun, Jun 28, 2015 at 9:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
That sucks. It was easy to see that the old fallback barrier
implementation wasn't re-entrant, but this one should be. And now
that I look at it again, doesn't the failure message
Robert Haas robertmh...@gmail.com writes:
What we did do that touched s_lock.h was attempt to ensure that
SpinLockAcquire() and SpinLockRelease() function as compiler barriers,
so that it should no longer be necessary to litter the code with
volatile in every function that uses those. It is
Alvaro Herrera wrote:
Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Uh. I'm pretty sure there were some back when that patch went in. And
there definitely used to be a couple earlier. I guess itanium really is
dying (mixed bad: It's a horrible architecture, but more
Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Uh. I'm pretty sure there were some back when that patch went in. And
there definitely used to be a couple earlier. I guess itanium really is
dying (mixed bad: It's a horrible architecture, but more coverage would
still be good).
On 2015-05-20 16:21:57 -0300, Alvaro Herrera wrote:
In HEAD only. Previous branches seem mostly clean, so there's something
going wrong. Spinlocks going wrong perhaps?
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anoledt=2015-05-20%2016%3A30%3A26stg=check
! PANIC: stuck
On 2015-05-20 16:44:12 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
Hm. Anole hasn't reported reliably for a while before these. It's quite
possible that this is a ac++ portability problem around the
atomics. There's lots of other IA64 animals not having problems, but
they're not
Andres Freund and...@anarazel.de writes:
On 2015-05-20 16:44:12 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
Hm. Anole hasn't reported reliably for a while before these. It's quite
possible that this is a ac++ portability problem around the
atomics. There's lots of other IA64 animals not
In HEAD only. Previous branches seem mostly clean, so there's something
going wrong. Spinlocks going wrong perhaps?
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anoledt=2015-05-20%2016%3A30%3A26stg=check
! PANIC: stuck spinlock (cd6f4140) detected at lwlock.c:816
!
Andres Freund wrote:
On 2015-05-20 16:21:57 -0300, Alvaro Herrera wrote:
In HEAD only. Previous branches seem mostly clean, so there's something
going wrong. Spinlocks going wrong perhaps?
On 2015-05-20 16:21:57 -0300, Alvaro Herrera wrote:
In HEAD only. Previous branches seem mostly clean, so there's something
going wrong. Spinlocks going wrong perhaps?
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anoledt=2015-05-20%2016%3A30%3A26stg=check
! PANIC: stuck
On 5/20/15 3:09 PM, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-20 16:44:12 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
Lots? As far as I can tell, this is the only Itanium machine in the
buildfarm.
...
(It's times like this that I regret not working for Red
26 matches
Mail list logo
