I have pg segfaults on two boxes, a DL160G6 and a DL380g5.
I've just checked their memory with memtest86+ v2.11
No errors were detected.
We also monitor the boxes via IPMI, and there are no signs
of HW failures.
Regards,
Daniel
Tom Lane wrote:
> Nagy Daniel writes:
>> I ran "select * from" on
Nagy Daniel writes:
> I have pg segfaults on two boxes, a DL160G6 and a DL380g5.
> I've just checked their memory with memtest86+ v2.11
> No errors were detected.
> We also monitor the boxes via IPMI, and there are no signs
> of HW failures.
Hm. Well, now that 8.4.2 is out, the first thing you o
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The new explain formats break if you have a multi-query statement.
I don't have time to fix at the moment, but I'll try and explain
the problem. For YAML, the for
On Mon, Dec 14, 2009 at 12:32 PM, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> The new explain formats break if you have a multi-query statement.
> I don't have time to fix at the moment, but I'll try and explain
> the problem. For YAML, the forced lead
The following bug has been logged online:
Bug reference: 5243
Logged by: Greg Johnson
Email address: greg.john...@interprose.com
PostgreSQL version: 8.4.1, 8.3.8
Operating system: CentOS 5.4
Description:Segmentation fault when sending null to crypt();
Details:
Postg
"Greg Johnson" writes:
> Postgresql version 8.4.1 and 8.3.8 both seg fault when you pass null into
> crypt function.
> select crypt(null, gen_salt('md5'));
Not if the crypt function is properly defined:
CREATE OR REPLACE FUNCTION crypt(text, text)
RETURNS text
AS 'MODULE_PATHNAME', 'pg_crypt'
L
On Mon, Dec 14, 2009 at 12:59 PM, Robert Haas wrote:
>> The new explain formats break if you have a multi-query statement.
> I will fix this, unless someone else beats me to it.
Proposed patch attached. The problem with JSON output is pretty
simple - ExplainSeparatePlans() still thinks it's resp
I have a few things to report so I'm not sure if one email is good or
several but here goes.
We are using Postgresql 8.3.8
We were having a blocking query problem that should have been fixed by
statement_timeout = 9 however this seems to have had zero effect.
The query we have was like so:
On 15/12/2009 12:35 PM, Mark Williamson wrote:
So what happened is, the above update never completed and the Postgresql
service consumed all available memory. We had to forcefully reboot the
machine
That means your server is misconfigured. PostgreSQL should never consume
all available memory
The following bug has been logged online:
Bug reference: 5244
Logged by: Philip Graham
Email address: phi...@lightbox.org
PostgreSQL version: 8.3.8
Operating system: Linux
Description:Attempting to rollback to a savepoint after receiving an
error with state 55000 the
10 matches
Mail list logo