On 14 Feb 2012, at 18:28, Tom Lane wrote:
>
> Oh, I see the reason for this: the code in cclass() in regc_locale.c
> doesn't go further up than U+00FF, so no codes above that will be
> thought to be letters (or members of any other character class).
> Clearly we need to go further when we are deal
On 14 Feb 2012, at 18:28, Tom Lane wrote:
>
> Oh, I see the reason for this: the code in cclass() in regc_locale.c
> doesn't go further up than U+00FF, so no codes above that will be
> thought to be letters (or members of any other character class).
> Clearly we need to go further when we are deal
On 9 Feb 2012, at 15:02, Tom Lane wrote:
> Duncan Rance writes:
>> Our customers are keen to get the official release as soon as possible. They
>> are on 9.0.6, so I guess this'll be 9.0.7? I'm new here so I don't know how
>> long this might take, and I
On 8 Feb 2012, at 10:01, Duncan Rance wrote:
> On 6 Feb 2012, at 20:48, Tom Lane wrote:
>
>> bug reports. Please see if you can break REL9_0_STABLE branch tip
>
> Just to let you know that I built this yesterday and I'm giving it a good
> battering in our Solaris
On 6 Feb 2012, at 20:48, Tom Lane wrote:
> bug reports. Please see if you can break REL9_0_STABLE branch tip
Just to let you know that I built this yesterday and I'm giving it a good
battering in our Solaris 10 Sparc test environment.
D
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgre
On 3 Feb 2012, at 06:45, Tom Lane wrote:
>
> I probably ought to let the test case run overnight before concluding
> anything, but at this point it's run for two-plus hours with no errors
> after applying this patch:
>
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/trans
On 2 Feb 2012, at 18:02, Duncan Rance wrote:
>
> At last I have been able to reproduce this problem in a relatively simple
> (yet contrived) way.
Doh! Should have mentioned this already, but in case a Sparc is not available,
the latest on the debugging is as follows:
As well as the
On 1 Feb 2012, at 22:37, Duncan Rance wrote:
> On 1 Feb 2012, at 21:43, Tom Lane wrote:
>
>> If you could post complete instructions for duplicating this, we
>> could probably find the cause fairly quickly.
>
> I've been on this for over a week now, and mu
I recently raised "BUG #6425: Bus error in slot_deform_tuple". During the last
reproduction of the problem I saw this:
Client 2 aborted in state 0: ERROR: invalid memory alloc request size
18446744073709551613
So like Tom said, these two issues could well be related. I just wanted to
mention
I recently raised "BUG #6425: Bus error in slot_deform_tuple". During the last
reproduction of the problem I saw this:
Client 2 aborted in state 0: ERROR: invalid memory alloc request size
18446744073709551613
So like Tom said, these two issues could well be related. I just wanted to
mention
On 1 Feb 2012, at 21:43, Tom Lane wrote:
>> Client 87 aborted in state 8: ERROR: wrong hoff: 134
>
> Yowza. Is this just the standard pgbench test, or something else?
This is pgbench with a custom script (-f option.)
> If you could post complete instructions for duplicating this, we
> could pr
On 1 Feb 2012, at 18:10, Robert Haas wrote:
> I went looking for commits that might be relevant to this that are new
> in 9.0.6, also present in 9.1.2 (per 6200), and related to t_hoff, and
> came up with this one:
>
> Branch: master [039680aff] 2011-11-04 23:22:50 -0400
I looked at this and it s
On 1 Feb 2012, at 16:04, Tom Lane wrote:
> postg...@dunquino.com writes:
>> This is intermittent and hard to reproduce but crashes consistently in the
>> same place. That place is backend/access/common/heaptuple.c line 1104:
>> ...
>> This system is using streaming replication, and the problem alw
13 matches
Mail list logo
