On Wed, Sep 24, 2014 at 2:45 PM, Andres Freund and...@2ndquadrant.com 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
On Tue, Sep 9, 2014 at 6:00 PM, Andres Freund and...@2ndquadrant.com 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
On 2014-09-04 08:18:37 -0400, Robert Haas wrote:
On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund and...@2ndquadrant.com
wrote:
If you want to do that, it's fine with me. What I would do is:
- Back-patch the
On Mon, Sep 8, 2014 at 7:10 PM, Andres Freund and...@2ndquadrant.com 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
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
On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund and...@2ndquadrant.com 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
On 2014-09-09 17:30:44 -0400, Robert Haas wrote:
On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund and...@2ndquadrant.com 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
On Tue, Sep 9, 2014 at 5:32 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-09 17:30:44 -0400, Robert Haas wrote:
On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
I had forgotten that it needed an update.
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 the
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 Mon, Sep 8, 2014 at 8:07 AM, Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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?
On Mon, Sep 8, 2014 at 10:07 AM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Sep 8, 2014 at 10:08:04AM -0400, Robert Haas wrote:
On Mon, Sep 8, 2014 at 8:07 AM, Andres Freund and...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund and...@2ndquadrant.com 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
On September 4, 2014 2:18:37 PM CEST, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas robertmh...@gmail.com
wrote:
On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund
and...@2ndquadrant.com wrote:
If you want to do that, it's fine with me. What I would do is:
On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund and...@2ndquadrant.com 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
On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas robertmh...@gmail.com 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
On 2014-07-06 15:02:21 -0400, Robert Haas wrote:
On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas robertmh...@gmail.com 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
On 2014-07-01 20:21:37 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On 02/07/14 08:36, Andres Freund wrote:
On 2014-07-01 20:21:37 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On Wed, Jul 2, 2014 at 4:06 AM, Mark Cave-Ayland
mark.cave-ayl...@ilande.co.uk 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
On 2014-06-30 22:44:58 -0400, Robert Haas wrote:
On Mon, Jun 30, 2014 at 6:28 PM, Andres Freund and...@2ndquadrant.com 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
On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund and...@2ndquadrant.com 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
On Tue, Jul 1, 2014 at 11:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund and...@2ndquadrant.com 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
On 2014-07-01 11:46:19 -0500, Merlin Moncure wrote:
On Tue, Jul 1, 2014 at 11:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund and...@2ndquadrant.com
wrote:
You know, looking at this, I wonder if we shouldn't just remove
support for ARMv5
On Tue, Jul 1, 2014 at 12:46 PM, Merlin Moncure mmonc...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, Jul 1, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, Jul 1, 2014 at 4:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
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 of
Andres Freund and...@2ndquadrant.com 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
On Sat, Jun 28, 2014 at 9:41 AM, Andres Freund and...@2ndquadrant.com 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
Hi,
On 2014-06-30 08:03:40 -0400, Robert Haas wrote:
On Sat, Jun 28, 2014 at 9:41 AM, Andres Freund and...@2ndquadrant.com 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
On Mon, Jun 30, 2014 at 9:26 AM, Andres Freund and...@2ndquadrant.com 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
On 2014-06-30 10:05:44 -0400, Robert Haas wrote:
On Mon, Jun 30, 2014 at 9:26 AM, Andres Freund and...@2ndquadrant.com 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,
On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund and...@2ndquadrant.com 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
On 2014-06-30 11:38:31 -0400, Robert Haas wrote:
On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund and...@2ndquadrant.com
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 +
On Mon, Jun 30, 2014 at 12:20 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-30 11:38:31 -0400, Robert Haas wrote:
On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund and...@2ndquadrant.com
wrote:
Now, we want to make these
operations compiler fences as well, and AIUI your proposal
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 memory barrier
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 own
On Mon, Jun 30, 2014 at 6:28 PM, Andres Freund and...@2ndquadrant.com 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
On 2014-06-27 22:34:19 -0400, Robert Haas wrote:
On Fri, Jun 27, 2014 at 2:04 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-27 13:04:02 -0400, Robert Haas wrote:
On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On Sat, Jun 28, 2014 at 4:31 AM, Andres Freund and...@2ndquadrant.com 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
On 2014-06-28 09:25:32 -0400, Robert Haas wrote:
On Sat, Jun 28, 2014 at 4:31 AM, Andres Freund and...@2ndquadrant.com 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
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 can
On Thu, Jun 26, 2014 at 5:01 PM, Andres Freund and...@2ndquadrant.com 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
On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com 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
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
is an
On 2014-06-27 13:04:02 -0400, Robert Haas wrote:
On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com 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
On Fri, Jun 27, 2014 at 2:04 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-27 13:04:02 -0400, Robert Haas wrote:
On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
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.
Andres Freund and...@2ndquadrant.com 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?
On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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?
Andres Freund and...@2ndquadrant.com 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
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
On 2014-06-26 15:40:11 -0700, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
60 matches
Mail list logo
