Re: [BUGS] BUG #7781: pgagent incorrect installation
On Thu, Jan 3, 2013 at 8:44 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7781
> Logged by: Alexander Shniperson
> Email address: alex.shniper...@gmail.com
> PostgreSQL version: 9.1.7
> Operating system: osx lion 10.7.5
> Description:
>
> Hi.
>
> Just installed last PostgreSQL 9.1.7 and installed pgAgent from Application
> builder, but when i run pgAdmin no Jobs at all and even more in console i
> have error "com.apple.launchd: (com.edb.launchd.pgagent[55389])
> posix_spawn("/Library/pgAgent/bin/pgagent", ...): No such file or directory
> "
> fix it please, thanks.
Please try the 3.3.0 update that was just released.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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 #7785: Bad plan for UNION ALL view containing JOIN
The following bug has been logged on the website: Bug reference: 7785 Logged by: Dag Lem Email address: d...@nimrod.no PostgreSQL version: 9.2.1 Operating system: RedHat EL 5.8 Description: Hi, The test case below demonstrates that the planner pushes down the WHERE (ON) clause in a UNION ALL view, but fails to push down the WHERE (ON) clause when a JOIN clause is introduced in the view. Any simple fix? :-) Best regards, Dag Lem create table a2 ( pk integer primary key, val2 integer ); create table a1 ( pk integer primary key, val1 integer, pk_a2 integer ); create table b ( pk integer primary key, val1 integer, val2 integer ); create table c ( pk integer ); insert into a2 select generate_series(1,1), random()*1000; insert into a1 select s, random(), s%2 from generate_series(1,99) s; insert into b select generate_series(111, 200), random()*1000; insert into c select generate_series(980001, 102); analyze a1; analyze a2; analyze b; analyze c; create view ab_good as select a1.pk, val1 from a1 union all select pk, val1 from b; create view ab_bad as select a1.pk, val1, val2 from a1 left join a2 on (a2.pk = a1.pk) union all select pk, val1, val2 from b; explain analyze select ab.pk, ab.val1 from c left join ab_good ab on (ab.pk = c.pk); explain analyze select ab.pk, ab.val1, ab.val2 from c left join ab_bad ab on (ab.pk = c.pk); *** ab_good - Good query plan *** QUERY PLAN Nested Loop Left Join (cost=0.00..75682.00 rows=189 width=8) (actual time= 0.037..702.184 rows=4 loops=1) -> Seq Scan on c (cost=0.00..577.00 rows=4 width=4) (actual time=0.011. .50.068 rows=4 loops=1) -> Append (cost=0.00..1.86 rows=2 width=8) (actual time=0.010..0.012 rows=0 loops=4) -> Index Scan using a1_pkey on a1 (cost=0.00..0.98 rows=1 width=8) (a ctual time=0.003..0.004 rows=0 loops=4) Index Cond: (pk = c.pk) -> Index Scan using b_pkey on b (cost=0.00..0.88 rows=1 width=8) (act ual time=0.003..0.003 rows=0 loops=4) Index Cond: (pk = c.pk) Total runtime: 750.259 ms (8 rows) *** ab_bad - Bad query plan *** QUERY PLAN --- Hash Right Join (cost=1077.64..98329.41 rows=189 width=12) (actual time=85 58.418..13902.096 rows=4 loops=1) Hash Cond: (a1.pk = c.pk) -> Append (cost=0.64..50002.41 rows=189 width=12) (actual time=0.054..9 710.313 rows=189 loops=1) -> Merge Left Join (cost=0.64..27119.41 rows=99 width=12) (actual time=0.050..4057.602 rows=99 loops=1) Merge Cond: (a1.pk = a2.pk) -> Index Scan using a1_pkey on a1 (cost=0.00..24278.66 rows=990 000 width=8) (actual time=0.024..1575.131 rows=99 loops=1) -> Index Scan using a2_pkey on a2 (cost=0.00..240.75 rows=1 width=8) (actual time=0.015..15.589 rows=1 loops=1) -> Seq Scan on b (cost=0.00..12983.00 rows=90 width=12) (actual t ime=0.011..1119.213 rows=90 loops=1) -> Hash (cost=577.00..577.00 rows=4 width=4) (actual time=103.728..103. 728 rows=4 loops=1) Buckets: 4096 Batches: 1 Memory Usage: 1407kB -> Seq Scan on c (cost=0.00..577.00 rows=4 width=4) (actual time= 0.011..49.449 rows=4 loops=1) Total runtime: 13950.038 ms (12 rows) -- 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 #7786: select from view is computing columns not selected
The following bug has been logged on the website: Bug reference: 7786 Logged by: Douglas Toltzman Email address: d...@oakstreetsoftware.com PostgreSQL version: 9.2.2 Operating system: Linux CentOS Description: in the interest of simplicity, I've got a view that calls a stored procedure to compute a value ... create view testv as select tt.field1, tt.intfield, compute_val(tt.field1) AS compute1 from tt; If compute_val() selects sum(intfield) from the testv view, compute_val() is called again when selecting records from testv (even though compute1 was not selected), resulting in infinite recursion (stack overflow). In retrospect, I realize this may have been a bad thing to do, but it worked in version 8.1.x. I recently upgraded to 9.2.2 and I had to create a 2nd view that didn't include the computed values, so I could use that view in the stored procedures. It seems like a performance problem to compute all columns in a view when selecting only specific columns. I've already fixed my stack overflow, so I'll let you decide if this is a bug or a feature. If you're interested in reproducing this and you don't understand my description, I'd be happy to provide a test case. -- 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 #7781: pgagent incorrect installation
On Fri, Jan 4, 2013 at 3:15 PM, Aleksander Shniperson wrote: > I can't do that, every time i run ApplicationBuilder i see new version 3.3.0, > then i chose "next next next" and nothing changes. > Define "nothing changes" please. Do you mean it doesn't fix the problem? It works fine for me here: raptor:server dpage$ ps -ef |grep pgagent 502 87069 1 0 3:22pm ?? 0:00.08 /Library/pgAgent/bin/pgagent -f -l1 -s /var/log/pgagent.log host=localhost port=5434 dbname=postgres user=postgres 501 87102 87078 0 3:24pm ttys0040:00.00 grep pgagent raptor:server dpage$ sudo launchctl unload /Library/LaunchDaemons/com.edb.launchd.pgagent.plist raptor:server dpage$ ps -ef |grep pgagent 501 87108 87078 0 3:24pm ttys0040:00.00 grep pgagent raptor:server dpage$ sudo launchctl load /Library/LaunchDaemons/com.edb.launchd.pgagent.plist raptor:server dpage$ ps -ef |grep pgagent 502 87114 1 0 3:24pm ?? 0:00.04 /Library/pgAgent/bin/pgagent -f -l1 -s /var/log/pgagent.log host=localhost port=5434 dbname=postgres user=postgres 501 87117 87078 0 3:24pm ttys0040:00.00 grep pgagent -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #7781: pgagent incorrect installation
On Fri, Jan 4, 2013 at 3:43 PM, Aleksander Shniperson wrote: > Sorry. > > It does not fix the problem. > >> /Library/pgAgent > path not exists. So where did you install it if that path doesn't exist? My suggestion would be to figure that out, then uninstall the old version before starting over with the new - e.g. sudo open /Library/pgAgent/uninstall-pgagent.app -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #7781: pgagent incorrect installation
"e.g." means "for example". Once you've figured out where it is installed, you should substitute the correct path into the example I gave. On Fri, Jan 4, 2013 at 4:28 PM, Aleksander Shniperson wrote: > LoL > > path /Library/pgAgent does not exists, i can't run uninstall > > 04.01.2013, в 20:18, Dave Page написал(а): > >> On Fri, Jan 4, 2013 at 3:43 PM, Aleksander Shniperson >> wrote: >>> Sorry. >>> >>> It does not fix the problem. >>> /Library/pgAgent >>> path not exists. >> >> So where did you install it if that path doesn't exist? My suggestion >> would be to figure that out, then uninstall the old version before >> starting over with the new - e.g. >> >> sudo open /Library/pgAgent/uninstall-pgagent.app >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #7781: pgagent incorrect installation
On Fri, Jan 4, 2013 at 4:35 PM, Aleksander Shniperson wrote: > sudo find / -name "uninstall-pgagent.app" > > gives no result. What's in /etc/postgres-reg.ini? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #7785: Bad plan for UNION ALL view containing JOIN
d...@nimrod.no writes: > The test case below demonstrates that the planner pushes down the WHERE (ON) > clause in a UNION ALL view, but fails to push down the WHERE (ON) clause > when a JOIN clause is introduced in the view. > Any simple fix? :-) No. (See is_safe_append_member() for why not.) 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
Re: [BUGS] BUG #7786: select from view is computing columns not selected
d...@oakstreetsoftware.com writes: > in the interest of simplicity, I've got a view that calls a stored procedure > to compute a value ... > create view testv as select tt.field1, tt.intfield, compute_val(tt.field1) > AS compute1 from tt; > If compute_val() selects sum(intfield) from the testv view, compute_val() is > called again when selecting records from testv (even though compute1 was not > selected), resulting in infinite recursion (stack overflow). > In retrospect, I realize this may have been a bad thing to do, but it worked > in version 8.1.x. I suspect that your function is declared VOLATILE, possibly by default. PG versions later than 8.1 refrain from flattening views that contain volatile functions in their SELECT list, on the grounds that such a transformation might remove side-effects that the user expects to have happen, or even cause the side-effects to happen more often than expected. If you can declare the function STABLE then the view should continue to work as before. 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
