On Wed, Sep 24, 2014 at 2:45 PM, Andres Freund wrote:
> On 2014-09-09 17:54:03 -0400, Robert Haas wrote:
>> So, that's committed, then. I think we should pick something that uses
>> spinlocks and is likely to fail spectacularly if we haven't got this
>> totally right yet, and de-volatilize it. An
On 2014-09-09 17:54:03 -0400, Robert Haas wrote:
> So, that's committed, then. I think we should pick something that uses
> spinlocks and is likely to fail spectacularly if we haven't got this
> totally right yet, and de-volatilize it. And then watch to see what
> turns red in the buildfarm and/or
On Tue, Sep 9, 2014 at 6:00 PM, Andres Freund wrote:
> On 2014-09-09 17:54:03 -0400, Robert Haas wrote:
>> So, that's committed, then.
>
> Yay, finally.
>
>> I think we should pick something that uses
>> spinlocks and is likely to fail spectacularly if we haven't got this
>> totally right yet, and
On 2014-09-09 17:54:03 -0400, Robert Haas wrote:
> So, that's committed, then.
Yay, finally.
> I think we should pick something that uses
> spinlocks and is likely to fail spectacularly if we haven't got this
> totally right yet, and de-volatilize it. And then watch to see what
> turns red in th
On Tue, Sep 9, 2014 at 5:32 PM, Andres Freund wrote:
> On 2014-09-09 17:30:44 -0400, Robert Haas wrote:
>> On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund wrote:
>> > On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
>> >> I had forgotten that it needed an update. Thanks for the reminder.
>> >> H
On 2014-09-09 17:30:44 -0400, Robert Haas wrote:
> On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund wrote:
> > On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
> >> I had forgotten that it needed an update. Thanks for the reminder.
> >> Here's v2.
> >
> > I've attached a incremental patch fixing m
On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund wrote:
> On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
>> I had forgotten that it needed an update. Thanks for the reminder. Here's
>> v2.
>
> I've attached a incremental patch fixing minor gripes. Other than that I
> think you can go ahead with
On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
> I had forgotten that it needed an update. Thanks for the reminder. Here's
> v2.
I've attached a incremental patch fixing minor gripes. Other than that I
think you can go ahead with this once the buildfarm accepts the sparc
fixes (man, those mac
On Mon, Sep 8, 2014 at 7:10 PM, Andres Freund wrote:
>> This has been pending for almost two months now and, at your request,
>> my patch to make spinlocks act as compiler barriers is waiting behind
>> it. Can we please get this moving again soon, or can I commit that
>> patch and you can fix thi
On 2014-09-04 08:18:37 -0400, Robert Haas wrote:
> On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas wrote:
> > On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund
> > wrote:
> >>> > If you want to do that, it's fine with me. What I would do is:
> >>> >
> >>> > - Back-patch the addition of the sparcv8+ st
Robert Haas writes:
> But what we're talking about here is a bug fix for Sparc. And surely
> we ought to back-patch that.
Ah. OK, no objection.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On Mon, Sep 8, 2014 at 10:08:04AM -0400, Robert Haas wrote:
> On Mon, Sep 8, 2014 at 8:07 AM, Andres Freund wrote:
> > On 2014-09-04 14:19:47 +0200, Andres Freund wrote:
> >> Yes. I plan to push the patch this weekend. Sorry for the delay.
> >
> > I'm about to push this. Is it ok to first push it
On Mon, Sep 8, 2014 at 10:07 AM, Tom Lane wrote:
> It makes for a cleaner commit history if you push concurrently into
> all the branches you intend to patch. That also gives more buildfarm
> runs, which seems like a good thing for this sort of patch.
>
> That is, assuming that we ought to backpa
Andres Freund writes:
> On 2014-09-04 14:19:47 +0200, Andres Freund wrote:
>> Yes. I plan to push the patch this weekend. Sorry for the delay.
> I'm about to push this. Is it ok to first push it to master and only
> backpatch once a couple buildfarm cycles haven't complained?
It makes for a clea
On Mon, Sep 8, 2014 at 8:07 AM, Andres Freund wrote:
> On 2014-09-04 14:19:47 +0200, Andres Freund wrote:
>> Yes. I plan to push the patch this weekend. Sorry for the delay.
>
> I'm about to push this. Is it ok to first push it to master and only
> backpatch once a couple buildfarm cycles haven't
On 2014-09-04 14:19:47 +0200, Andres Freund wrote:
> Yes. I plan to push the patch this weekend. Sorry for the delay.
I'm about to push this. Is it ok to first push it to master and only
backpatch once a couple buildfarm cycles haven't complained?
Greetings,
Andres Freund
--
Andres Freund
On September 4, 2014 2:18:37 PM CEST, Robert Haas wrote:
>On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas
>wrote:
>> On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund
> wrote:
> If you want to do that, it's fine with me. What I would do is:
>
> - Back-patch the addition of the sparcv8+ s
On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas wrote:
> On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund wrote:
>>> > If you want to do that, it's fine with me. What I would do is:
>>> >
>>> > - Back-patch the addition of the sparcv8+ stuff all the way. If
>>> > anyone's running anything older, let
On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund wrote:
>> > If you want to do that, it's fine with me. What I would do is:
>> >
>> > - Back-patch the addition of the sparcv8+ stuff all the way. If
>> > anyone's running anything older, let them complain...
>> > - Remove the special case for MIPS wi
On 2014-07-06 15:02:21 -0400, Robert Haas wrote:
> On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas wrote:
> >>> Since we have a Sun Studio machine in the buildfarm, we shouldn't give
> >>> up on SPARC completely, but maybe we should only add the cases for
> >>> sparcv8+ and above? That at least has
On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas wrote:
>>> Since we have a Sun Studio machine in the buildfarm, we shouldn't give
>>> up on SPARC completely, but maybe we should only add the cases for
>>> sparcv8+ and above? That at least has some chance of getting tested.
>>
>> That we have code fo
On Wed, Jul 2, 2014 at 4:06 AM, Mark Cave-Ayland
wrote:
> The point I wanted to make was that there are certain applications for which
> SPARCv8 is still certified for particular military/aerospace use. While I
> don't use it myself, some people are still using it enough to want to
> contribute QE
On 02/07/14 08:36, Andres Freund wrote:
On 2014-07-01 20:21:37 -0400, Tom Lane wrote:
Andres Freund writes:
On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote:
Also if you're struggling for Sun buildfarm animals, recent versions of QEMU
will quite happily install and run later versions of
On 2014-07-01 20:21:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote:
> >> Also if you're struggling for Sun buildfarm animals, recent versions of
> >> QEMU
> >> will quite happily install and run later versions of 32-bit Solaris over
> >>
Andres Freund writes:
> On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote:
>> Also if you're struggling for Sun buildfarm animals, recent versions of QEMU
>> will quite happily install and run later versions of 32-bit Solaris over
>> serial, and 2.0 even manages to give you a cgthree framebuffe
On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote:
> On 01/07/14 11:04, Andres Freund wrote:
>
> >>Since we have a Sun Studio machine in the buildfarm, we shouldn't give
> >>up on SPARC completely, but maybe we should only add the cases for
> >>sparcv8+ and above? That at least has some chance
On 01/07/14 11:04, Andres Freund wrote:
Since we have a Sun Studio machine in the buildfarm, we shouldn't give
up on SPARC completely, but maybe we should only add the cases for
sparcv8+ and above? That at least has some chance of getting tested.
That we have code for sparcv7 is ridiculous bt
On Tue, Jul 1, 2014 at 4:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> Despite my concerns about keeping the list of supported atomics short,
>> and I do have concerns in that area, I'm not really sure that we have
>> much choice but to go in that direction. We can't accept a >5x
>> performanc
Robert Haas writes:
> Despite my concerns about keeping the list of supported atomics short,
> and I do have concerns in that area, I'm not really sure that we have
> much choice but to go in that direction. We can't accept a >5x
> performance hit in the name of portability, and that's literally
On Tue, Jul 1, 2014 at 2:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> The bottom line is that I love supporting obscure platforms as much as
>> anyone here, and several other committers are already telling me that
>> I love it too much. We've got to draw the line somewhere, and I think
>> ref
Robert Haas writes:
> The bottom line is that I love supporting obscure platforms as much as
> anyone here, and several other committers are already telling me that
> I love it too much. We've got to draw the line somewhere, and I think
> refusing to ship newly-written code that we have exactly z
On Tue, Jul 1, 2014 at 12:46 PM, Merlin Moncure wrote:
> A few years back I ported the postresql client libraries and a few
> other pieces of software (in particular subversion) to a lot of
> obscure platforms (old sparc, hpux, irix, older aix, etc etc).
> Getting a modern gcc working on those pla
On 2014-07-01 11:46:19 -0500, Merlin Moncure wrote:
> On Tue, Jul 1, 2014 at 11:22 AM, Robert Haas wrote:
> > On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund
> > wrote:
> >>> You know, looking at this, I wonder if we shouldn't just remove
> >>> support for ARMv5 instead of making a blind stab at a
On Tue, Jul 1, 2014 at 11:22 AM, Robert Haas wrote:
> On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund wrote:
>>> You know, looking at this, I wonder if we shouldn't just remove
>>> support for ARMv5 instead of making a blind stab at a fix.
>>
>> Well, I argued that way for a while ;). We don't even
On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund wrote:
>> You know, looking at this, I wonder if we shouldn't just remove
>> support for ARMv5 instead of making a blind stab at a fix.
>
> Well, I argued that way for a while ;). We don't even need to really
> desupport it, but just say it's not suppo
On 2014-06-30 22:44:58 -0400, Robert Haas wrote:
> On Mon, Jun 30, 2014 at 6:28 PM, Andres Freund wrote:
> > On 2014-06-30 19:22:59 +0200, Andres Freund wrote:
> >> On 2014-06-30 12:46:29 -0400, Robert Haas wrote:
> >> >, which if I understand you correctly are ARM without GCC
> >> > atomics, Spar
On Mon, Jun 30, 2014 at 6:28 PM, Andres Freund wrote:
> On 2014-06-30 19:22:59 +0200, Andres Freund wrote:
>> On 2014-06-30 12:46:29 -0400, Robert Haas wrote:
>> >, which if I understand you correctly are ARM without GCC
>> > atomics, Sparc, and MIPS.
>>
>> I've to revise my statement on MIPS, it
On 2014-06-30 19:22:59 +0200, Andres Freund wrote:
> On 2014-06-30 12:46:29 -0400, Robert Haas wrote:
> >, which if I understand you correctly are ARM without GCC
> > atomics, Sparc, and MIPS.
>
> I've to revise my statement on MIPS, it actually looks safe. I seem to
> have missed that it has its
On 2014-06-30 12:46:29 -0400, Robert Haas wrote:
> >> But trying to use a spinlock
> >> acquire-release to shore up problems with the spinlock release
> >> implementation makes my head explode.
> >
> > Well, it actually makes some sense. Nearly any TAS() implementation is
> > going to have some mem
On Mon, Jun 30, 2014 at 12:20 PM, Andres Freund wrote:
> On 2014-06-30 11:38:31 -0400, Robert Haas wrote:
>> On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund
>> wrote:
>> >> Now, we want to make these
>> >> operations compiler fences as well, and AIUI your proposal for that is
>> >> to make NEW_S
On 2014-06-30 11:38:31 -0400, Robert Haas wrote:
> On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund
> wrote:
> >> Now, we want to make these
> >> operations compiler fences as well, and AIUI your proposal for that is
> >> to make NEW_S_UNLOCK(lock) = out of line function call + S_LOCK(dummy)
> >>
On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund wrote:
>> > Solaris seems to run with TSO enabled for SPARC (whereas linux uses RMO,
>> > relaxed memory ordering), so it's probably fine to just use the compiler
>> > barrier.
>>
>> If it isn't, that's a change that has nothing to do with making
>>
On 2014-06-30 10:05:44 -0400, Robert Haas wrote:
> On Mon, Jun 30, 2014 at 9:26 AM, Andres Freund wrote:
> > I think it continues in the tradition of making s_lock.h ever harder to
> > follow. But it's still better than what we have now from a correctness
> > perspective.
>
> Well, as you and I h
On Mon, Jun 30, 2014 at 9:26 AM, Andres Freund wrote:
> I think it continues in the tradition of making s_lock.h ever harder to
> follow. But it's still better than what we have now from a correctness
> perspective.
Well, as you and I have discussed before, someday we probably need to
get rid of
Hi,
On 2014-06-30 08:03:40 -0400, Robert Haas wrote:
> On Sat, Jun 28, 2014 at 9:41 AM, Andres Freund wrote:
> >> No, I think it's going to be *much* simpler than that. How about I
> >> take a crack at this next week and then either (a) I'll see why it's a
> >> bad idea and we can go from there
On Sat, Jun 28, 2014 at 9:41 AM, Andres Freund wrote:
>> No, I think it's going to be *much* simpler than that. How about I
>> take a crack at this next week and then either (a) I'll see why it's a
>> bad idea and we can go from there or (b) you can review what I come up
>> with and tell me why i
On 2014-06-28 15:41:46 +0200, Andres Freund wrote:
> On 2014-06-28 09:25:32 -0400, Robert Haas wrote:
> > No, I think it's going to be *much* simpler than that. How about I
> > take a crack at this next week and then either (a) I'll see why it's a
> > bad idea and we can go from there or (b) you c
On 2014-06-28 09:25:32 -0400, Robert Haas wrote:
> On Sat, Jun 28, 2014 at 4:31 AM, Andres Freund wrote:
> >> > Do we want to introduce acquire/release barriers? Or do we want to
> >> > redefine the current barriers to be strong enough for that?
> >>
> >> Well, unless we're prepared to dump suppor
On Sat, Jun 28, 2014 at 4:31 AM, Andres Freund wrote:
>> > Do we want to introduce acquire/release barriers? Or do we want to
>> > redefine the current barriers to be strong enough for that?
>>
>> Well, unless we're prepared to dump support for an awful lot of
>> platfomrs, trying to support acqui
On 2014-06-27 22:34:19 -0400, Robert Haas wrote:
> On Fri, Jun 27, 2014 at 2:04 PM, Andres Freund wrote:
> > On 2014-06-27 13:04:02 -0400, Robert Haas wrote:
> >> On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane wrote:
> >> > Andres Freund writes:
> >> >> On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
>
On Fri, Jun 27, 2014 at 2:04 PM, Andres Freund wrote:
> On 2014-06-27 13:04:02 -0400, Robert Haas wrote:
>> On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane wrote:
>> > Andres Freund writes:
>> >> On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
>> >>> Surely it had better be a read barrier as well?
>> >
On 2014-06-27 13:04:02 -0400, Robert Haas wrote:
> On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
> >>> Surely it had better be a read barrier as well?
> >
> >> I don't immediately see why it has to be read barrier? Ho
On 2014-06-27 13:00:34 -0400, Robert Haas wrote:
> There are two separate issues here:
>
> 1. SpinLockAcquire and SpinLockRelease are not guaranteed to be
> compiler barriers, so all relevant memory accesses in the critical
> section need to be done using volatile pointers. Failing to do this
> i
On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
>>> Surely it had better be a read barrier as well?
>
>> I don't immediately see why it has to be read barrier? Hoisting a load
>> from after the release into the locked area
On Thu, Jun 26, 2014 at 5:01 PM, Andres Freund wrote:
> But a) isn't really avoidable because it'll otherwise generate compiler
> warnings and b) is done that way all over the tree. E.g. lwlock.c has
> several copies of (note the nonvolatility of proc):
> volatile LWLock *lock = l;
>
On 2014-06-26 15:40:11 -0700, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
> >> Surely it had better be a read barrier as well?
>
> > I don't immediately see why it has to be read barrier? Hoisting a load
> > from after the release into the locked area
Hi,
On 2014-06-26 23:01:10 +0200, Andres Freund wrote:
> I think we should rework things so that we fall back to
> pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what
> we have right now.
> That'd require to make barrier.h independent from s_lock.h, but I think
> that'd be a p
Andres Freund writes:
> On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
>> Surely it had better be a read barrier as well?
> I don't immediately see why it has to be read barrier? Hoisting a load
> from after the release into the locked area of code should be safe?
No doubt, but delaying a read ti
On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
> Andres Freund writes:
> > I think we should rework things so that we fall back to
> > pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what
> > we have right now.
>
> Surely it had better be a read barrier as well?
I don't immedi
Andres Freund writes:
> I think we should rework things so that we fall back to
> pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what
> we have right now.
Surely it had better be a read barrier as well? And S_LOCK the same?
regards, tom lane
--
Se
Hi,
I just spent 20+ hours debugging a elusive problem which only happened
under heavy concurrency. Slight changes to the code made it
disappear. In the end it turned out that gcc liked to move *one*
instruction across the SpinLockRelease() - and only sometimes. Unrelated
changes made the vanish.
61 matches
Mail list logo
