Re: [BUGS] 9.3beta2 unrecognized node type in join alias vars when retrieving view definition
On 2013-07-22 13:22:21 +0200, Feike Steenbergen wrote: While testing the 9.3 beta I am unable to get the view definition for some views. Because of this I cannot use pg_dump to create a valid dump of the specified database. Any chance you can post a schema only dump from 9.2 that reproduces the problem when loaded into 9.3? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8317: ROUND(double*1/2) != ROUND(1/2*double)
The following bug has been logged on the website: Bug reference: 8317 Logged by: Rémi Email address: remi.c...@gmail.com PostgreSQL version: 9.2.4 Operating system: Ubuntu 12.0.4 32 bits hosted by a VirtualBox Description: Hello; I ran into a strange behaviour. Initially it showed in a group by, but is also happens in regular select : example : SELECT 2*ROUND(1/2*3.2) -- gives 0 SELECT 2*ROUND(3.2*1/2) -- gives 3 Obviously both should return the same thing, preferably 3. It looks like a bug to me, or at least a non desirable behaviour. Cheers, Rémi -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8317: ROUND(double*1/2) != ROUND(1/2*double)
On 2013-07-22 09:44:58 +, remi.c...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 8317 Logged by: Rémi Email address: remi.c...@gmail.com PostgreSQL version: 9.2.4 Operating system: Ubuntu 12.0.4 32 bits hosted by a VirtualBox Description: Hello; I ran into a strange behaviour. Initially it showed in a group by, but is also happens in regular select : example : SELECT 2*ROUND(1/2*3.2) -- gives 0 SELECT 2*ROUND(3.2*1/2) -- gives 3 Obviously both should return the same thing, preferably 3. It looks like a bug to me, or at least a non desirable behaviour. Hm. Doesn't really look like a bug to me. The first parses as: ROUND((1/2) * 3.2), the second as ROUND((3.2 * 1) / 2). So the different result makes sense to me. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8317: ROUND(double*1/2) != ROUND(1/2*double)
2013/7/22 remi.c...@gmail.com: The following bug has been logged on the website: Bug reference: 8317 Logged by: Rémi Email address: remi.c...@gmail.com PostgreSQL version: 9.2.4 Operating system: Ubuntu 12.0.4 32 bits hosted by a VirtualBox Description: Hello; I ran into a strange behaviour. Initially it showed in a group by, but is also happens in regular select : example : SELECT 2*ROUND(1/2*3.2) -- gives 0 SELECT 2*ROUND(3.2*1/2) -- gives 3 Hello It is not a bug - a reason for this behave is using a integer div in first case ( 1 / 2 ) * 3.2 ... 1/2 .. integer div, because left operand is int and right operand is int (3.2 * 1) / 2 ... 3.2 / 2 .. using numeric div, left operand is numeric and right operand is int Regards Pavel Stehule Obviously both should return the same thing, preferably 3. It looks like a bug to me, or at least a non desirable behaviour. Cheers, Rémi -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.3beta2 unrecognized node type in join alias vars when retrieving view definition
the attached dump can be loaded and results in an error message when retrieving the view definitions. On Mon, Jul 22, 2013 at 2:04 PM, Feike Steenbergen feikesteenber...@gmail.com wrote: I can reproduce it with the attached dump. On Mon, Jul 22, 2013 at 1:26 PM, Andres Freund and...@2ndquadrant.com wrote: only unrecognized_node_type_bug-dump.sql Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.3beta2 unrecognized node type in join alias vars when retrieving view definition
Feike Steenbergen feikesteenber...@gmail.com writes: the attached dump can be loaded and results in an error message when retrieving the view definitions. Thanks for the test case. It looks like I broke this in commit 2ffa740b, as a result of believing the comment in parsenodes.h that says joinaliasvars lists can only contain Vars or COALESCE expressions :-(. Will fix. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8318: memory leak during CREATE TEMPORARY TABLE
The following bug has been logged on the website: Bug reference: 8318 Logged by: G.Bakalarski Email address: g.bakalar...@icm.edu.pl PostgreSQL version: 9.1.3 Operating system: Linux Debian 6 (squeezy) Description: When doing these kind of statements (this is from log file): 2013-07-21 02:29:26 UTC [16683] composite LOG: duration: 630631.234 ms execute unnamed: CREATE TEMPORARY TABLE tmp2_4da9ce5d_bf86_4331_a18d_4c918cdd71de AS SELECT contributorMD5, contributorFirstName, contributorFirstName_sortkey, contributorLastName, contributorLastName_sortkey, contributorTitle, contributorTitle_sortkey, contributorLastFirstName_sortkey, contributorLastFirstName_plain, contributorFirstLastName, contributorFirstLastName_plain, COUNT(*) AS _aggregated FROM rel_2_repContributorView AS _main WHERE _tick $1 AND _tick = $2 AND contributorType = $3 GROUP BY contributorMD5, contributorFirstName, contributorFirstName_sortkey, contributorLastName, contributorLastName_sortkey, contributorTitle, contributorTitle_sortkey, contributorLastFirstName_sortkey, contributorLastFirstName_plain, contributorFirstLastName, contributorFirstLastName_plain UNION ALL SELECT contributorMD5, contributorFirstName, contributorFirstName_sortkey, contributorLastName, contributorLastName_sortkey, contributorTitle, contributorTitle_sortkey, contributorLastFirstName_sortkey, contributorLastFirstName_plain, contributorFirstLastName, contributorFirstLastName_plain, -COUNT(*) AS _aggregated FROM del_2_repContributorView AS _main WHERE _tick $4 AND _tick = $5 AND _origtick = $6 AND (contributorType = $7) GROUP BY contributorMD5, contributorFirstName, contributorFirstName_sortkey, contributorLastName, contributorLastName_sortkey, contributorTitle, contributorTitle_sortkey, contributorLastFirstName_sortkey, contributorLastFirstName_plain, contributorFirstLastName, contributorFirstLastName_plain 2013-07-21 02:29:26 UTC [16683] composite DETAIL: parameters: $1 = '6', $2 = '1160', $3 = 'PERSON', $4 = '6', $5 = '1160', $6 = '6', $7 = 'PERSON' a commited system memory measured with sar -r , goes up by 2-20GBytes and never goes down eg: 00:00:01kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit 01:55:01 76347732 122133736 61.53 0 29816912 116970332 58.93 02:05:01 75886088 122595380 61.77 0 30289504 116960972 58.93 02:15:01 75317968 123163500 62.05 0 30814996 117007696 58.95 02:25:01 31505704 166975764 84.13 0 73817200 117399024 59.15 02:35:01 439584 198041884 99.78 0 90340732 131819000 66.41 02:45:01 436480 198044988 99.78 0 89510732 131750320 66.38 02:55:01 14986680 183494788 92.45 0 75110884 132450980 66.73 03:05:01 15881024 182600444 92.00 0 74202256 132465840 66.74 03:15:01 45572732 152908736 77.04 0 45209796 132472464 66.74 03:25:01 44059268 154422200 77.80 0 46752888 132480808 66.75 03:35:01 42515568 155965900 78.58 0 48230784 132536984 66.78 03:45:01 40578860 157902608 79.56 0 50224608 132477148 66.75 03:55:01 38876772 159604696 80.41 0 51858264 132495080 66.75 04:05:01 72974428 125507040 63.23 0 18578900 132527424 66.77 This happens (noticeably) when statement last long enough (short lasting statements don't pull up memory). After few days (such long lasting Create temp table happens few time a day), my huge server (192GB of RAM), gets stucked due to no memory available (usually %commit is around 103-105%), linux OOM killer goes into action - it usually kills one of postgres processes - postmaster restart all databases) and after all linux has again some 100GB of not commited memory (-- sar -r). Looking in rel notes of PG 9.1.4+ I did not see any fixes on this ... GB -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8317: ROUND(double*1/2) != ROUND(1/2*double)
Hi, thanks for your quick answers. To close this non-bug : According to the doc ( http://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html#SQL-SYNTAX-OPERATORS ) , multiplication has precedence on division. (I supposed it implicitely) So anyway the query is parsed as ( 1/ (2*3.2)) and ( 3.2*1) / 2 ), and so the behaviour is consistant. Cheers , Rémi 2013/7/22 Pavel Stehule pavel.steh...@gmail.com 2013/7/22 remi.c...@gmail.com: The following bug has been logged on the website: Bug reference: 8317 Logged by: Rémi Email address: remi.c...@gmail.com PostgreSQL version: 9.2.4 Operating system: Ubuntu 12.0.4 32 bits hosted by a VirtualBox Description: Hello; I ran into a strange behaviour. Initially it showed in a group by, but is also happens in regular select : example : SELECT 2*ROUND(1/2*3.2) -- gives 0 SELECT 2*ROUND(3.2*1/2) -- gives 3 Hello It is not a bug - a reason for this behave is using a integer div in first case ( 1 / 2 ) * 3.2 ... 1/2 .. integer div, because left operand is int and right operand is int (3.2 * 1) / 2 ... 3.2 / 2 .. using numeric div, left operand is numeric and right operand is int Regards Pavel Stehule Obviously both should return the same thing, preferably 3. It looks like a bug to me, or at least a non desirable behaviour. Cheers, Rémi -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
