On Tue, Mar 18, 2014 at 4:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane 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.
>
>
Robert Haas writes:
> On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane 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 worth explicitly testing zero-byte
On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane 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 size and messa
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 (pgsql-hackers@postgresql.org)
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.
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,
On Tue, Mar 18, 2014 at 1:16 PM, Tom Lane 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
> -Wformat-secur
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
I wrote:
> Robert Haas 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
---
/Users/buildfarm/bf-data/HEAD/pgsql.93630
Robert Haas 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
parameter. It'd be nice
All right.
On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane 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
On Tue, Mar 18, 2014 at 10:44 AM, Tom Lane 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.
OK, committe
Robert Haas writes:
> On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane 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 tempted to just put in
>> a static
On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane wrote:
> Robert Haas 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)
>> > MAXI
Robert Haas 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 platforms where t
On Mon, Mar 17, 2014 at 1:26 PM, Robert Haas 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 always a Size but align t
On Mon, Mar 17, 2014 at 12:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Mar 16, 2014 at 10:45 PM, Tom Lane 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
Robert Haas writes:
> On Sun, Mar 16, 2014 at 10:45 PM, Tom Lane 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.
> Well, the problem is with this:
On Sun, Mar 16, 2014 at 10:45 PM, Tom Lane wrote:
> Robert Haas 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
>> mul
Robert Haas 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 great deal of addi
On Sun, Mar 16, 2014 at 11:26 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane 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 wo
Robert Haas writes:
> On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane 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 the size of the shared memory
>>
On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane 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 UTF8 locale
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
24 matches
Mail list logo
