haddock | 25 Apr 16:38 2013
Picon

BUG #8117: simple but huge query infinite execution time

The following bug has been logged on the website:

Bug reference:      8117
Logged by:          Viacheslav Seledkin
Email address:      haddock <at> mail.ru
PostgreSQL version: 9.2.3
Operating system:   Linux, Windows
Description:        

you can get query here 
http://yadi.sk/d/uE-KE0b34LV5A

query has the following scheme
SELECT 
	regexp_matches('...',' (\d+)\:','g'), 
	regexp_matches('...','\:([\d\.]+)','g')

where '...' is approximately 40kb string (the same in both ...)

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

nitinmn | 25 Apr 15:52 2013
Picon

BUG #8116: create trigger after insert fails if procedure being executed is having error

The following bug has been logged on the website:

Bug reference:      8116
Logged by:          CREATE TRIGGER AFTER INSERT FAILS
Email address:      nitinmn <at> gmail.com
PostgreSQL version: 9.1.7
Operating system:   WINDOWS , UNIX
Description:        

when we create a trigger for a table which basically runs triggers a
procedure after insert.now if the procedure has some error when executing ,
the insert also fails, But ideally since this trigger is defined after
insert , the insert should have been successful.
eg
CREATE OR REPLACE FUNCTION insert_send_mail_function()
RETURNS "trigger" AS
$BODY$
use Mail::Sendmail;

$str = substr trim($_TD->{new}{url}),3;
$subject = "Login Alert : ".$_TD->{new}{username}.", ";
message  = "URL accessed: ".$_TD->{new}{url}."\n";
%mail = ( From => $_[0], To => $_[1], Subject => $subject , Message =>
$message);

sendmail(%mail) or die $Mail::Sendmail::error;
return undef;
$BODY$
LANGUAGE 'plperlu' VOLATILE;

(Continue reading)

danielcristian | 25 Apr 13:06 2013
Picon

BUG #8115: Increased session memory usage after pg_upgrade

The following bug has been logged on the website:

Bug reference:      8115
Logged by:          Daniel Cristian Cruz
Email address:      danielcristian <at> gmail.com
PostgreSQL version: 9.2.4
Operating system:   CentOS release 5.5, Linux 2.6.18-194.32.1.el5 #1 S
Description:        

I had a server with PostgreSQL 9.1.4 which I tried to upgrade to 9.2.4 with
pg_upgrade.

After the upgrade I got a working server where some queries were using more
memory than old version.

Details in thread:

http://www.postgresql.org/message-id/CACffM9F-aSTopQ3G0mZvyWusp=RPZ=MmnPn26MKVtDb5r-JaDw <at> mail.gmail.com

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

support | 25 Apr 00:21 2013

BUG #8114: Peer authentication in cgi-perl

The following bug has been logged on the website:

Bug reference:      8114
Logged by:          Kenneth Robinette
Email address:      support <at> securenetterm.com
PostgreSQL version: 9.1.0
Operating system:   Ubuntu 12.04.2
Description:        

I am having the same problem described in:
 	5.1.0.14.2.20020213180151.04bd2250 <at> pop.ntlworld.com 

The cgi-script I am using works on a CentOS 6.4 system using PostgreSQL
version 8.4 and several older centos/redhat systems.  The pg_hba.conf and
postgresql.conf are setup the same on all systems.

When trying to connect On the Ubuntu 12.04.2 system, the database connect is
aborted.  The following messages are in the postgresql-9.1-main.log.  The
real username has been replaced by xxxxxxxx:

2013-04-24 16:23:18 CDT LOG:  provided user name (xxxxxxxx) and
authenticated user name (www-data) do not match
2013-04-24 16:23:18 CDT FATAL:  Peer authentication failed for user
"xxxxxxxx"

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

(Continue reading)

Heikki Linnakangas | 24 Apr 18:04 2013

Re: BUG #8091: No permissions on the table file causing recovery failure

On 24.04.2013 08:01, Hari Babu wrote:
> As the following raised bug is not received by the bugs mailing list.
> Forwarding the same to mailing list.
>
> http://www.postgresql.org/message-id/E1USmqv-0006X0-5X <at> wrigleys.postgresql.o
> rg
>
> Please check the above defect needs any handling?

> 1. create table.
> 2. change the file permissions.
> 3. Drop table.
> 4. Restart the server leads to recovery failure.

I think the answer to that is "don't do that". There is an arbitrary 
number of ways you can make the system fail, if you mess with the files 
in the data directory. This is just one of them.

- Heikki

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

umberto.brighetti | 24 Apr 16:38 2013
Picon

BUG #8113: odbc

The following bug has been logged on the website:

Bug reference:      8113
Logged by:          umberto brighetti
Email address:      umberto.brighetti <at> gmail.com
PostgreSQL version: 9.2.4
Operating system:   win 7
Description:        

accessig data from win pgsql odbc (ansi or unicode) record inserted are not
editable. the error indicate another user is modifing (false concurrent
edit). Instead new records are well saved
which can be the problem?
I use odbc connetting pgsql db to ms access
thanks

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hari Babu | 24 Apr 07:01 2013

BUG #8091: No permissions on the table file causing recovery failure

As the following raised bug is not received by the bugs mailing list.
Forwarding the same to mailing list.

http://www.postgresql.org/message-id/E1USmqv-0006X0-5X <at> wrigleys.postgresql.o
rg

Please check the above defect needs any handling?

Regards,
Hari babu.

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Kanitchet Vaiassava | 23 Apr 17:24 2013
Picon

Fw: [pgadmin-support] (Bug) Numeric fault calculation

Dear,
 
       I had forwarded my bug report from pgadmin-support to pgsql-bugs (with attach file) and sorry for send it to pgadmin-support 
and please allows me to quote more form pg’s document and do more underline

8.1.3. Floating-Point Types

The data types real and double precision are inexact, variable-precision numeric types. In practice, these types are usually implementations of IEEE Standard 754 for Binary Floating-Point Arithmetic (single and double precision, respectively), to the extent that the underlying processor, operating system, and compiler support it.

Inexact means that some values cannot be converted exactly to the internal format and are stored as approximations, so that storing and retrieving a value might show slight discrepancies. Managing these errors and how they propagate through calculations is the subject of an entire branch of mathematics and computer science and will not be discussed here, except for the following points:

  • If you require exact storage and calculations (such as for monetary amounts), use the numeric type instead.

  • If you want to do complicated calculations with these types for anything important, especially if you rely on certain behavior in boundary cases (infinity, underflow), you should evaluate the implementation carefully.

  • Comparing two floating-point values for equality might not always work as expected.

 

Please fix this, and if you have any suggestion to workaround right now it will be great.

sorry for bad english.

Thank you.

 
Best Regards,
Kanitchet Vaiassava

ThaiAce Capital Co., Ltd
999 Nawamin Rd., Nuanjun, Buengkum, Bangkok 10230, Thailand
Mobile +66 89 515 9955; Office +66 2 944 2000 Ext.1204; Fax +66 2 944 2020
---------------------------------------------------------------------------------------------------------------
 
Sent: Tuesday, April 23, 2013 5:06 PM
Subject: Re: Fw: [pgadmin-support] (Bug) Numeric fault calculation
 
Intresting thing. I never thought it is so loose.
On the other side, I would never use double for currency calculations. It provides instability to results due to floating point precision.

However due to this:

The scale of a numeric is the count of decimal digits in the fractional part, to the right of the decimal point

Try to this:
SELECT (260739.94 * (1.00000000000000000000000000000/365))
_____________________
714.3560000000000000000000000714356


With regards


On 23.4.2013 11:17, Kanitchet Vaiassava wrote:

Dear pg's support and Alexander

 

Allow me to quote this reference from : http://www.postgresql.org/docs/9.1/static/datatype-numeric.html

"The type numeric can store numbers with a very large number of digits and perform calculations exactly. It is especially recommended for storing monetary amounts and other quantities where exactness is required. However, arithmetic on numeric values is very slow compared to the integer types, or to the floating-point types described in the next section.

We use the following terms below: The scale of a numeric is the count of decimal digits in the fractional part, to the right of the decimal point. The precision of a numeric is the total count of significant digits in the whole number, that is, the number of digits to both sides of the decimal point. So the number 23.5141 has a precision of 6 and a scale of 4. Integers can be considered to have a scale of zero."

 
Thai is the documentation that has been show right now. It's mean that others developer may using this recommended "numeric" in financial and accounting which is mission critical. right?
 
So I think this problem should be solve? or at least, it should be note in document for other developer to be more careful.
 
 
 
Sent: Tuesday, April 23, 2013 3:48 PM
Subject: Re: [pgadmin-support] (Bug) Numeric fault calculation
 
Try
 
select (260739.94::double precision * (1.00::double precision / 365.00::double precision) )
 
default precision in postgres is pretty lossy, use double precision whenever you need max precision.
 
 


2013/4/23 Kanitchet Vaiassava <kanichet <at> hotmail.com>
(Bug) Numeric fault calculation
 
My company has using postgresql as database for ERP application which in-house developed.
For store financial and accounting data, we chose "numeric" type for accurate calculation (and with recommend by postgres's documentation) and we faced the problem by using "double precision" before.
 
However, we found that by using numeric had the problem too.
In our formula for calculate interest for customer's overdue payment that using numeric,
we found that it had fault calculate. So, it effected our interest amount.
 
In the attached file you can see that the result from postgresql and by using long division method is difference.
 
postgresql : 714.35599999999xxxx
long division method: 714.356
 
and if we multiply this result with interest rate and others factor and round up later. the amount is miscalculate.
 
Thank you and sorry for bad english gramma.
 
 
Best Regards,
Kanitchet Vaiassava
ThaiAce Group
555 Nawamin Rd., Klongkum, Buengkum, Bangkok 10230, Thailand
Mobile +66 89 515 9955; Office +66 2 744 2288; Fax +66 2 379 1166
---------------------------------------------------------------------------------------------------------------


--
Sent via pgadmin-support mailing list (pgadmin-support <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support




--
Regards,
Alexander Yerenkow


--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
roberto.menoncin | 23 Apr 18:18 2013
Picon

BUG #8107: How to downgrade database from 9.2.3 to 8.4 ?

The following bug has been logged on the website:

Bug reference:      8107
Logged by:          Roberto
Email address:      roberto.menoncin <at> netspa.it
PostgreSQL version: 9.2.3
Operating system:   CentOS 5.6 (Final)
Description:        

Hy.

This is not a bug but a simple request !

Is there a way to downgrade a database from version 9.2.3 to 8.4.x ?

I tried a pg_dump from 9.2.3 and a pg_restore from 9.2.3 TO a 8.4.7 server.

but I receive several errors.

Does it exist another way ?

Thank you.

Roby

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

ams214 | 23 Apr 09:54 2013
Picon
Picon

BUG #8106: Redundant function definition in contrib/cube/cube.c

The following bug has been logged on the website:

Bug reference:      8106
Logged by:          Adrian Schreyer
Email address:      ams214 <at> cam.ac.uk
PostgreSQL version: 9.2.4
Operating system:   Ubuntu 12.04 LTS
Description:        

The cube.c file in the cube contrib module contains a prototype for the
function Datum cube(PG_FUNCTION_ARGS). The prototype seems to be an artifact
from an older version because the function is never defined and also never
used in the code.

http://doxygen.postgresql.org/cube_8c_source.html#l00052

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

pg | 22 Apr 16:12 2013
Picon

BUG #8105: names are transformed to lowercase incorrectly

The following bug has been logged on the website:

Bug reference:      8105
Logged by:          András Kolesár
Email address:      pg <at> kolesar.hu
PostgreSQL version: 9.1.5
Operating system:   Windows 
Description:        

If I specify an unicode field name without quotes, field name gets lowecased
incorrectly. pgAdmin 1.14.2 on Linux, PostgreSQL server 9.1.5 on Windows:

SELECT érték FROM (SELECT 1 AS "érték") AS x;

********** Error **********
SQL state: 42703
Character: 8

In the example above I specify an unicode column name ("érték" means "value"
in Hungarian), then I try to read it. If I use double quotes in the outer
query, it works.

However, the above example works fine if the server runs on Linux:

"PostgreSQL 9.1.9 on i686-pc-linux-gnu, compiled by gcc (Ubuntu/Linaro
4.7.2-2ubuntu1) 4.7.2, 32-bit"

I see the same problem from PHP client. There is a more verbose error
message:

ERROR:  column "�rt�k" does not exist
LINE 1: SELECT érték FROM (SELECT 1 AS "érték") AS x
               ^

The "é" character is represented incorrectly in the error message, it shows
where the problem is. This character (U+00E9) is represented in UTF8 as C3
A9. In the error message it is an invalid UTF8 sequence: E3 A9. I think
Windows uses Windows-1250 or Windows-1252 character set where C3 lowers to
E3. A9 survives tolower() because it means © (copyright sign) in these
charsets, without lowercase pair.

I have localized the problem in PostgreSQL source:
src/backend/parser/scansup.c:128

char *
downcase_truncate_identifier(const char *ident, int len, bool warn) {
// ...
for (i = 0; i < len; i++)
// ...
	if (IS_HIGHBIT_SET(ch) && isupper(ch))
		ch = tolower(ch);

This function walks through identifiers byte-by-byte, lowers them if they
were individual characters. This is incorrect in multibyte character sets.
It works on Linux with UTF8 system encoding because isupper() returns false
both for C3 and A9.

The same issue is reported below:

Database object names and libpq in UTF-8 locale on Windows
http://permalink.gmane.org/gmane.comp.db.postgresql.sql/29464

Solution 1: tolower() only A-Z.
Solution 2: use a lowercase function that uses client_encoding

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Gmane