The following bug has been logged online:
Bug reference: 6035
Logged by: Daniel Schreiber
Email address: daniel.schrei...@ergora.eu
PostgreSQL version: 9.0.4
Operating system: Debian Squeeze
Description:server crash when executing recursive query (trying to
allocate 1
Testing 9.1beta:
select format('Hello %s, %2147483648$s', 'World');
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The problem i
Dean Rasheed writes:
> Testing 9.1beta:
> select format('Hello %s, %2147483648$s', 'World');
> server closed the connection unexpectedly
Yeah, same here.
> do
> {
> /* Treat overflowing arg position as
> unterminated. */
On 23.05.2011 17:33, Tom Lane wrote:
Not sure I trust this fix to catch all cases --- seems like the addition
could still overflow. It'd probably be better if we made this code look
like the overflow test in scanint8:
int64 newtmp = tmp * 10 + (*ptr++ - '0');
Heikki Linnakangas writes:
> It's a stretch that we'd ever support two billion arguments in any form,
> but an explicit check for "arg < 0" would make me feel better.
No objection here, especially since I've just determined that bug #6035
is also some kind of unhandled-overflow problem...
Do yo
"Daniel Schreiber" writes:
> Description:server crash when executing recursive query (trying to
> allocate 16 Exabyte memory)
> Details:
> When I execute the query at
> http://www.ergora.eu/data/postgresql/rekursiv_sl.sql on the data at
> http://www.ergora.eu/data/postgresql/crashdump.s
On Sun, May 15, 2011 at 5:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 12, 2011 at 6:20 PM, Tom Lane wrote:
>>> One possibility is to start showing "default" when the ACL is null,
>>> which would be quite easy to implement:
>>>
>>> COALESCE(array_to_string(c.relacl, E'\n'),
On Mon, May 16, 2011 at 8:04 AM, Pascal Borschneck
wrote:
> Hi Robert,
>
> Sorry for the late reply, I was not here last week.
>
> About your question: "*That's kind of surprising, but I can't help
> wondering if it's a bug in what virtualization tool you are using.*"
> I noticed the problem FIRS
On Wed, May 18, 2011 at 3:40 PM, Bruce Momjian wrote:
> Martin A. Brooks wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 6028
>> Logged by: Martin A. Brooks
>> Email address: mar...@antibodymx.net
>> PostgreSQL version: 9.0.4
>> Operating system: De
On 23.05.2011 18:36, Tom Lane wrote:
Heikki Linnakangas writes:
It's a stretch that we'd ever support two billion arguments in any form,
but an explicit check for "arg< 0" would make me feel better.
No objection here, especially since I've just determined that bug #6035
is also some kind of
Robert Haas writes:
> On Wed, May 18, 2011 at 3:40 PM, Bruce Momjian wrote:
>> Does anyone feel this is worth changing? I am concerned such a change
>> would break many user applications.
> The backward compatibility problem is pretty icky, but I don't much
> like the idea of leaving it as-is,
"Martin A. Brooks" writes:
> On Mon, May 23, 2011 19:02, Tom Lane wrote:
>> ISTM that changing interval's output formatting would create far too
>> many problems to be justifiable for such a purely cosmetic issue.
> I almost entirely agree with you except
> My current $dayjob is working in a
On Mon, May 23, 2011 19:50, Tom Lane wrote:
> I think possibly you misunderstand the scope of the breakage you're
> proposing. This is not about the age() function. It's interval_out()
> that's at stake, and so changing this would change the output formatting
> for *every* operation that yields i
On Tue, May 17, 2011 at 10:30 AM, dhaval wrote:
> The following bug has been logged online:
>
> Bug reference: 6027
> Logged by: dhaval
> Email address: d_dha...@rediffmail.com
> PostgreSQL version: 9.0
> Operating system: windows-7 , 64-bit
> Description: OLE DB Provid
On Mon, May 23, 2011 19:02, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 18, 2011 at 3:40 PM, Bruce Momjian wrote:
>>> Does anyone feel this is worth changing? I am concerned such a change
>>> would break many user applications.
>
>> The backward compatibility problem is pretty icky, but
On 23.05.2011 18:36, Tom Lane wrote:
Heikki Linnakangas writes:
It's a stretch that we'd ever support two billion arguments in any form,
but an explicit check for "arg< 0" would make me feel better.
No objection here, especially since I've just determined that bug #6035
is also some kind of
"Martin A. Brooks" wrote:
> My current $dayjob is working in an industry where details and
> aesthetics are everything. We will spend thousands of hours of
> processor time just to make sure than the sheen on an animal's fur
> will suggest "healthy and luxuriant" rather than "warm and moist".
>
I've not been able to duplicate this in a standalone script yet,
but in the guts of Bucardo is a trigger function called validate_goat()
that is giving this error on 9.1 HEAD, but not on previous versions:
"Failed to add table "public.pgbench_tellers": DBD::Pg::st execute
failed: ERROR: Modifi
On Mon, May 23, 2011 at 14:59, Greg Sabino Mullane wrote:
> I've not been able to duplicate this in a standalone script yet,
> but in the guts of Bucardo is a trigger function called validate_goat()
> that is giving this error on 9.1 HEAD, but not on previous versions:
>
> "Failed to add table "pu
On Mon, May 23, 2011 at 05:04:40PM -0600, Alex Hunsaker wrote:
...
> Greg, can you confirm the attached fixes it for you?
Yes, seems to have done the job, thank you.
--
Greg Sabino Mullane g...@endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
pgpmugDD5ToZ2.pgp
Description: PGP signature
20 matches
Mail list logo
