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 nagy.dan...@telekom.hu writes:
I
Nagy Daniel nagy.dan...@telekom.hu 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
-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
On Mon, Dec 14, 2009 at 12:32 PM, Greg Sabino Mullane g...@turnstep.com 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
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:
Greg Johnson greg.john...@interprose.com 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
On Mon, Dec 14, 2009 at 12:59 PM, Robert Haas robertmh...@gmail.com 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()
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
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