On Tue, Mar 18, 2014 at 4:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Meh. I think you're putting a bit too much faith in your ability to
predict the locus of bugs that you think
On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
OK, I tried this out. The major complication that cropped up was
that, if we make the length word always a Size but align the buffer to
MAXIMUM_ALIGNOF, then the length word might
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Would it get noticeably simpler or faster if you omitted support for
the sizeof(Size) MAXIMUM_ALIGNOF case? It looks like perhaps not,
but if we were paying anything much I'd be
On Tue, Mar 18, 2014 at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The thing I kind of like about this approach is that it makes the code
fully independent of the relationship between MAXIMUM_ALIGNOF and
sizeof(Size).
Yeah. If it's not costing us much to support both cases, let's do so.
All right.
On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Whilst setting up a buildfarm member on an old, now-spare Mac, I was
somewhat astonished to discover that contrib/test_shm_mq crashes thus:
TRAP: FailedAssertion(!(rb = sizeof(uint64)), File: shm_mq.c, Line: 429)
Robert Haas robertmh...@gmail.com writes:
First, can you retest this with the latest code?
Yeah, on it now.
If we want to inject some randomness into the test, which parameters
do we want to randomize and over what ranges?
I think the message length is the only particularly interesting
I wrote:
Robert Haas robertmh...@gmail.com writes:
First, can you retest this with the latest code?
Yeah, on it now.
Early returns not good:
***
/Users/buildfarm/bf-data/HEAD/pgsql.93630/contrib/test_shm_mq/expected/test_shm_mq.out
Tue Mar 18 12:00:18 2014
---
I wrote:
Early returns not good:
Also, these compiler messages are probably relevant:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g
On Tue, Mar 18, 2014 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Early returns not good:
Also, these compiler messages are probably relevant:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
On 2014-03-18 13:31:47 -0400, Robert Haas wrote:
Well, I definitely forgot that. I'll count myself lucky if that's the
only problem.
One minor thing missing, patch attached.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development,
and...@anarazel.de (Andres Freund) writes:
On 2014-03-18 13:31:47 -0400, Robert Haas wrote:
Well, I definitely forgot that. I'll count myself lucky if that's the
only problem.
One minor thing missing, patch attached.
setup_dynamic_shared_memory needed some more hacking too. Committed.
After the last round of changes, I can confirm that my original test with
UTF8 locale works, and my HPPA box is happy too. We could still stand
to improve the regression test though.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's tempting to instead add one or more tests that we specifically
choose to have values we think are likely to exercise
platform-specific differences or otherwise find bugs - e.g. just add a
second test where the queue
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Meh. I think you're putting a bit too much faith in your ability to
predict the locus of bugs that you think aren't there.
Well, I'm open to suggestions.
As a suggestion: it'd be
On Sun, Mar 16, 2014 at 10:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
But I think there's another possible problem here. In order for reads
from the buffer not to suffer alignment problems, the chunk size for
reads and writes from the buffer needs to
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 16, 2014 at 10:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it will result in padding space when you maxalign the length word,
but I don't see why it wouldn't work; and it would certainly be no less
efficient than what's there today.
On Mon, Mar 17, 2014 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 16, 2014 at 10:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it will result in padding space when you maxalign the length word,
but I don't see why it wouldn't work; and
On Mon, Mar 17, 2014 at 1:26 PM, Robert Haas robertmh...@gmail.com wrote:
Oh, yeah. Duh. Clearly my brain isn't working today. Hmm, so maybe
this will be fairly simple... will try it out.
OK, I tried this out. The major complication that cropped up was
that, if we make the length word
Robert Haas robertmh...@gmail.com writes:
OK, I tried this out. The major complication that cropped up was
that, if we make the length word always a Size but align the buffer to
MAXIMUM_ALIGNOF, then the length word might get split if sizeof(Size)
MAXIMUM_ALIGNOF.
Hmm ... do we support any
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
How is that leading to a crash? Well, this machine is 32-bit, so MAXALIGN
is only 4. This means it is possible for an odd-length message cum
message length word to not exactly divide
On Sun, Mar 16, 2014 at 11:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
How is that leading to a crash? Well, this machine is 32-bit, so MAXALIGN
is only 4. This means it is possible
Robert Haas robertmh...@gmail.com writes:
But I think there's another possible problem here. In order for reads
from the buffer not to suffer alignment problems, the chunk size for
reads and writes from the buffer needs to be MAXIMUM_ALIGNOF (or some
multiple of it). And in order to avoid a
On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Whilst setting up a buildfarm member on an old, now-spare Mac, I was
somewhat astonished to discover that contrib/test_shm_mq crashes thus:
TRAP: FailedAssertion(!(rb = sizeof(uint64)), File: shm_mq.c, Line: 429)
but only in
Whilst setting up a buildfarm member on an old, now-spare Mac, I was
somewhat astonished to discover that contrib/test_shm_mq crashes thus:
TRAP: FailedAssertion(!(rb = sizeof(uint64)), File: shm_mq.c, Line: 429)
but only in UTF8 locales, not in C locale. You'd have bet your last
dollar that that
24 matches
Mail list logo
