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
Ah, sorry, looks like it already fixed in
REL9_1_STABLE 5d7d12de56be2c746bfc30214d3300644e8dc0f3
Author: Tom Lane
Date: Tue Dec 20 19:57:40 2011 -0500
Fix gincostestimate to handle ScalarArrayOpExpr reasonably.
On Thu, Feb 2, 2012 at 4:35 AM, Sergey Burladyan wrote:
> Sergey Burladyan
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
Hi Tom,
Thanks for pointing the FAQ out, I did not see it.
I especially liked the link to http://explain.depesz.com - it's a useful
tool.
I succeeded to fix my problem by changing the order of JOINs (the query
remained exactly the same otherwise). According to EXPLAIN ANALIZE, it
eliminated those
The following bug has been logged on the website:
Bug reference: 6429
Logged by: seph
Email address: sephal...@hotmail.com
PostgreSQL version: 9.1.2
Operating system: Windows 7
Description:
i have reached till the point of inserting the password and retyping it for
ve
Thank you for the fast reply
I was not sure this was some spurious result messing up my calculations.
If it is by design and consistent it does not present any problems for
me.
For me the matter is closed.
Olaf
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Wedne
Andrew Schetinin writes:
> Previously I always thought that the order of JOINs or conditions in WHERE
> is irrelevant, and query optimizer rearranges the order according to its
> logic. Now it appears that sometimes it may be important.
If you have more than join_collapse_limit JOINs in the query
eshkinkot writes:
> Ah, sorry, looks like it already fixed in
> REL9_1_STABLE 5d7d12de56be2c746bfc30214d3300644e8dc0f3
Oh, of course. I couldn't reproduce it because I was testing 9.1
branch tip.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgre
A work around is:
- Delete the user called 'postgres' (if any)
- Create a new standard user 'postgres' from the control panel and set
password for it.
And, use this password at installation...
Remember - this is just a work around, not the complete solution.
--
Thanks & Regards,
Ashesh Vashi
En
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 much of that has been trying to
> simplif
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 bus error,
Duncan Rance writes:
> At last I have been able to reproduce this problem in a relatively simple
> (yet contrived) way.
> I've put together a tarball with a few scripts, some to be run on the primary
> and others to be run on the hot-stanby. There's a README in there explaining
> what to do.
I wrote:
> So far no luck reproducing any issue with this test case.
And I swear my finger had barely left the "send" key when:
TRAP: FailedAssertion("!(((lpp)->lp_flags == 1))", File: "heapam.c", Line: 735)
LOG: server process (PID 24740) was terminated by signal 6: Aborted
DETAIL: Failed proc
On Nov 16, 2011, at 1:29 PM, Kris Jurka wrote:
>
>
> On Tue, 15 Nov 2011, Teun Hoogendoorn wrote:
>
>>
>> The following bug has been logged online:
>>
>> Bug reference: 6293
>> PostgreSQL version: 9.1
>> Description:JDBC driver performance
>> Details:
>>
>> Using the postgresq
Sorry for the late reply, but Heikki, can you get this Itanium
information into s_lock.h as a comment, particularly the information
about the +Ovolatile=__unordered flag?
---
On Mon, Dec 19, 2011 at 11:25:06PM +0200, Heikki
I wrote:
> I have not gotten very far with the coredump, except to observe that
> gdb says the Assert ought to have passed: ...
> This suggests very strongly that indeed the buffer was changing under
> us.
I probably ought to let the test case run overnight before concluding
anything, but at this
Bridget Frey writes:
> I just wanted to say thanks to everyone who has been working so hard on
> this issue. I realize it's not certain that this would fix the issues
> we're seeing, but we'd be willing to try it out and report back. The only
> caveat is we would need to deploy it to production,
17 matches
Mail list logo
