Dear all,
since upgrading Ruby from 1.8.6.287 to 1.8.7.72, and recompiling
PL/ruby 0.5.0, functions written in PL/ruby may ignore their
given parameters and instead compute with undefined values,
providing nonsense results.
The test-suite provided with PL/ruby will show the problem.
Upgrading
On Wed, May 6, 2009 at 4:41 PM, Krimstock, Roger I (Roger)
wrote:
>
> Hopefully, this is the file that will provide the information. It does
> reference postgresql.conf.
Yep, it is the right file. The pertinent bit is this:
---
Ensuring we can write to the data directory (using cacls):
Are you
I wrote:
> I suppose the change I made here
> http://archives.postgresql.org/pgsql-committers/2009-04/msg00329.php
> to improve constant-join-qual handling is what is preventing the
> assertion failure, though I'm still not quite sure why (I'd better look
> closer to see if there is still some form
On Wed, May 06, 2009 at 01:26:05PM -0400, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > Tom Lane wrote:
> Oh! What is happening is that to_number(1) is being reduced to constant
> NULL, whereupon it concludes that ad_tab_id=to_number(1) is constant
> NULL, ergo the EXISTS can never succeed,
Alvaro Herrera writes:
> Heikki Linnakangas wrote:
>> Note that the function is immutable, and the argument in the query is a
>> constant. The planner simply runs the function and replaces the function
>> call with the result.
> The planner runs the function? Ok, neat -- I didn't know it did
Heikki Linnakangas wrote:
>> How can the executor "see through" a plpgsql function definition? Or do
>> you mean that this reduction is being done at execution time? (hmm ...
>> this is what a one-time filter is, now that I think about it?)
>
> Note that the function is immutable, and the argume
Alvaro Herrera wrote:
Tom Lane wrote:
Oh! What is happening is that to_number(1) is being reduced to constant
NULL, whereupon it concludes that ad_tab_id=to_number(1) is constant
NULL, ergo the EXISTS can never succeed, ergo the entire WHERE is
constant false.
CREATE FUNCTION to_number(inte
Tom Lane wrote:
> Oh! What is happening is that to_number(1) is being reduced to constant
> NULL, whereupon it concludes that ad_tab_id=to_number(1) is constant
> NULL, ergo the EXISTS can never succeed, ergo the entire WHERE is
> constant false.
> CREATE FUNCTION to_number(integer) RETURNS nume
Stefan Kaltenbrunner writes:
> Tom Lane wrote:
>> I was trying it on HEAD ... but I don't see any post-beta1 changes
>> in the cvs log that look like they might have fixed this ...
> confirmed - it does not crash on -HEAD for me as well but the plan
> generated by EXPLAIN looks kinda funny:
>
Tom Lane wrote:
Stefan Kaltenbrunner writes:
Tom Lane wrote:
Thank you for the report, but I do not see any problem when trying the
test case here. Do you have any nondefault planner parameter settings?
hmm weird - the testcase crashes for me as well on 8.4B1:
I was trying it on HEAD ...
Stefan Kaltenbrunner writes:
> Tom Lane wrote:
>> Thank you for the report, but I do not see any problem when trying the
>> test case here. Do you have any nondefault planner parameter settings?
> hmm weird - the testcase crashes for me as well on 8.4B1:
I was trying it on HEAD ... but I don't
On Wed, May 06, 2009 at 10:33:11AM -0400, Tom Lane wrote:
> Stefan Huehner writes:
> > I noticed the following bug when testing an application (openbravo 2.40) on
> > postgresql 8.4:
>
> Thank you for the report, but I do not see any problem when trying the
> test case here. Do you have any non
Tom Lane wrote:
Stefan Huehner writes:
I noticed the following bug when testing an application (openbravo 2.40) on
postgresql 8.4:
Thank you for the report, but I do not see any problem when trying the
test case here. Do you have any nondefault planner parameter settings?
hmm weird - the
Mikael Krantz wrote:
If you perform a recovery form a file system level backup postgres will
switch to a new timeline but the first WAL-log in with the new timeline will
contain the previous timeline.
If you start a backup immediately after recovery have completed the start of
the backup will be
Stefan Huehner writes:
> I noticed the following bug when testing an application (openbravo 2.40) on
> postgresql 8.4:
Thank you for the report, but I do not see any problem when trying the
test case here. Do you have any nondefault planner parameter settings?
regards,
The following bug has been logged online:
Bug reference: 4796
Logged by: Mikael Krantz
Email address: m...@zigamorph.se
PostgreSQL version: 8.3.7-0lenny1
Operating system: Linux (debian lenny)
Description:Recovery followed by backup creates unrecoverable
WAL-file
Deta
I noticed the following bug when testing an application (openbravo 2.40) on
postgresql 8.4:
Environment:
8.4beta
Package from: https://launchpad.net/~pitti/+archive/postgresql
recompiled for ubuntu intrepid
The following query does trigger the FailedAssertion:
SELECT ad_field.name As Name, ad_f
The following bug has been logged online:
Bug reference: 4795
Logged by: Madhu S R
Email address: s_r_ma...@yahoo.co.in
PostgreSQL version: postgres 8.0.3
Operating system: SunOS 5.9
Description:Solaris odbc Core Dump on Column NULL value
Details:
I am running an ap
Markus Meyer wrote:
The following bug has been logged online:
Bug reference: 4794
Logged by: Markus Meyer
Email address: mar...@7val.com
PostgreSQL version: 8.3.3
Operating system: Debian 2.6.22.19-vs2.2.0.7
Description:server closed the connection unexpectedly
Detai
On Wed, May 6, 2009 at 11:05 AM, Markus Meyer wrote:
> If i make an
>
> SELECT xmlconcat(('' || NULL || '')::xml);
>
> follows
>
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
It's fixed in
The following bug has been logged online:
Bug reference: 4794
Logged by: Markus Meyer
Email address: mar...@7val.com
PostgreSQL version: 8.3.3
Operating system: Debian 2.6.22.19-vs2.2.0.7
Description:server closed the connection unexpectedly
Details:
If i make an
On Tue, May 5, 2009 at 7:56 PM, Krimstock, Roger I (Roger)
wrote:
>
> The one click from downloads on www.postgres.org. Both the 8.3.7 and 8.4
> versions. The error message:
>
> ---
> Warning
> ---
> Problem running post-install step. Installation
22 matches
Mail list logo
