On 9 April 2011 00:41, Alvaro Herrera wrote:
> Excerpts from Brendan Jurd's message of vie abr 08 06:00:22 -0300 2011:
>> Memtest didn't report any errors. I intend to try swapping out the
>> RAM tomorrow, but in the meantime we got a *different* assertion
>> failure today. The fact that we are
On 7 April 2011 16:56, Tom Lane wrote:
> Brendan Jurd writes:
>> TRAP: FailedAssertion("!((data - start) == data_size)", File:
>> "heaptuple.c", Line: 255)
>
> [ scratches head ... ] That implies that heap_fill_tuple came to a
> different c
On 8 April 2011 00:16, Alvaro Herrera wrote:
> Excerpts from Brendan Jurd's message of jue abr 07 03:07:32 -0300 2011:
>> I am running a 9.0.3 Hot Standy + Streaming Replication slave which
>> occasionally segfaults (every 1-2 days). I rebuilt Postgres with
>> --enable-cassert and --enable-debug,
On 7 April 2011 16:56, Tom Lane wrote:
> Brendan Jurd writes:
>> TRAP: FailedAssertion("!((data - start) == data_size)", File:
>> "heaptuple.c", Line: 255)
>
> [ scratches head ... ] That implies that heap_fill_tuple came to a
> different c
Hi folks,
I am running a 9.0.3 Hot Standy + Streaming Replication slave which
occasionally segfaults (every 1-2 days). I rebuilt Postgres with
--enable-cassert and --enable-debug, switched on core dumping and
waited for some results.
The first crash since enabling debugging was a failed assert i
On 26 October 2010 03:42, Tom Lane wrote:
> Brendan Jurd writes:
>> Thanks for the hint; I found that the attached patch resolved my
>> specific segfault, but I am wondering whether it goes far enough.
>
> Well, it definitely doesn't go far enough, because the i
On 25 October 2010 07:36, Tom Lane wrote:
> Brendan Jurd writes:
>> I have encountered a reproducible segfault in Postgres ...
>
> Looks like the invalItems list has been clobbered:
>
> (gdb) p *root->glob->invalItems
> $6 = {type = 2139062143, length = 21390621
On 25 October 2010 07:36, Tom Lane wrote:
> Looks like the invalItems list has been clobbered:
>
> (gdb) p *root->glob->invalItems
> $6 = {type = 2139062143, length = 2139062143, head = 0x7f7f7f7f,
> tail = 0x7f7f7f7f}
>
> I'm guessing it was modified in the temporary memory context and not
> pro
Hi folks,
I have encountered a reproducible segfault in Postgres, and confirmed
it in 9.0.1 and HEAD on three separate machines. The bug was not
present in 8.4. I've attached a copy of the SQL script I have been
using to induce the segfault.
With asserts enabled, I get a failed assertion:
TRAP
2009/6/24 Jeremy Ford :
> I've just compiled and run the 8.4.RC2 code. For both of the following
> queries I get "0009-03-01"
>
> SELECT to_date(' 2009 03', ' MM') as extraspace; --returns
> "0009-03-01"
> SELECT to_date('2009 03', ' MM') as bogusspace; --returns "0009-03-01"
>
> Was it
2009/6/23 Tom Lane :
> Brendan Jurd writes:
>> I should be able to get the same results by snipping an extra
>> strspace_len() characters in the new code path in
>> from_char_parse_int_len(). This ought to be a one-line fix that
>> doesn't clobber the good parts o
2009/6/23 Tom Lane :
> I'm hesitant to fool with this post-RC, and we don't have "a couple of
> days" to wait for a fix --- 8.4.0 is scheduled to wrap on Thursday.
> However, I see that the first of these cases actually represents a
> regression from 8.3 and before; existing releases get 2009-03-01
2009/6/22 Jeremy Ford :
> Hi Brendan.
>
> Results as requested - Oracle 10g:
Cheers for that Jeremy.
I think we can safely conclude from these results that Oracle pays no
attention whatsoever to leading spaces in either the input string, or
the format string.
If we want to copy this behaviour, I
2009/6/22 Jeremy Ford :
> Oracle 9i:
> YEAR MONTH METHOD1 METHOD2
>
> 2009 03 1/03/2009 1/03/2009
>
> Oracle 10g:
> YEAR MONTH METHOD1 METHOD2
>
> 2009 03 1/03/2009 1/03/2009
>
Hi Jeremy,
The query you used above might not tell us
2009/6/19 Tom Lane :
> regression=# select to_date(' 2009 07', ' MM');
> to_date
>
> 2009-07-01
> (1 row)
>
> However, that just begs the question --- it seems that leading space is
> allowed in MM, just not in . Brendan, is that intentional or is it
> a bug?
>
The reason t
On Sat, Sep 27, 2008 at 12:11 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Agreed on separating the message issue. What I wanted to know was
> whether there are similar bugs elsewhere in to_timestamp, or whether
> you're pretty sure this is the only occurrence of the coding pattern?
I'm pretty sur
On Fri, Sep 26, 2008 at 8:05 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> A likely bet is that this is caused by use of uninitialized memory,
>> which happens to have garbage rather than zeroes in it the second
>> time throu
17 matches
Mail list logo
