On Sun, Jul 26, 2015 at 11:36 AM, Andres Freund 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=anole&br=HEAD
>
> Since there
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=anole&br=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 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 _Asm_double_magic_xyz
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
On 2015-06-29 23:05:55 -0400, Robert Haas wrote:
> Personally, I have found that _Asm_double_magic_xyzzy makes is not
> nearly as cromulent as _Asm_triple_magic_plugh. But then, trying to
> figure out compiler intrinsics on strange platforms makes me feel very
> much like I'm in a maze of twisty l
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 memory barrier is a
lot more robust and easy to under
On Mon, Jun 29, 2015 at 10:58 PM, 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. Or to put it
> differently: where is the evidence that removing the volatile qual is a
> good idea?
Robert Haas writes:
> On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund 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 don't see how volatile can create a C
On Mon, Jun 29, 2015 at 10:53 PM, Andres Freund wrote:
> On 2015-06-29 22:45:49 -0400, Robert Haas wrote:
>> On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund wrote:
>> > On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
>> >> On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund wrote:
>> >> > On 2015-06
On 2015-06-29 22:45:49 -0400, Robert Haas wrote:
> On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund wrote:
> > On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
> >> On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund wrote:
> >> > On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
> >> >> #define S_UNLOCK(l
On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund wrote:
> On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
>> On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund wrote:
>> > On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
>> >> #define S_UNLOCK(lock)\
>> >> do { _Asm_sched_fence(); (*(lock)
On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
> On Mon, Jun 29, 2015 at 6:11 AM, 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? Is
On Mon, Jun 29, 2015 at 6:11 AM, 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 thi
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
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 wh
Robert Haas 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 possible that
> t
On Sun, Jun 28, 2015 at 9:17 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 (cd6f4140) d
On Sun, Jun 28, 2015 at 9:10 PM, Robert Haas wrote:
> On Sun, Jun 28, 2015 at 7:27 PM, Tom Lane wrote:
>> I'd hoped that commit 1b468a131bd260c9041484f78b8580c7f232d580 would
>> resolve this, but nope, anole is still getting occasional stuck spinlocks:
>> http://buildfarm.postgresql.org/cgi-bin/s
On Sun, Jun 28, 2015 at 7:27 PM, Tom Lane wrote:
> I'd hoped that commit 1b468a131bd260c9041484f78b8580c7f232d580 would
> resolve this, but nope, anole is still getting occasional stuck spinlocks:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=anole&dt=2015-06-28%2021%3A35%3A02
That suc
Alvaro Herrera writes:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Andres Freund 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,
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Andres Freund 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 wou
Tom Lane wrote:
> Andres Freund 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).
>
> Since
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=anole&dt=2015-05-20%2016%3A30%3A26&stg=check
> ! PANIC: stu
On 5/20/15 3:09 PM, Tom Lane wrote:
Andres Freund 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 Hat any more,
and hav
Andres Freund 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 having
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
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?
> >
> > http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anole&dt=2015-05-20%2016%3A3
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=anole&dt=2015-05-20%2016%3A30%3A26&stg=check
> ! PANIC: st
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=anole&dt=2015-05-20%2016%3A30%3A26&stg=check
! PANIC: stuck spinlock (cd6f4140) detected at lwlock.c:816
! ser
30 matches
Mail list logo
