Re: [BUGS] BUG #6502: Missing Link at Version Tracker
On Fri, Mar 2, 2012 at 06:41, wrote: > The following bug has been logged on the website: > > Bug reference: 6502 > Logged by: Ronald Hofmann > Email address: pro...@jumbosoft.de > PostgreSQL version: Unsupported/Unknown > Operating system: MacOSX Lion > Description: > > I haven´t used PG for some time and since I didn´t find anything on your > site, only a download for 10.4. which is really old, I moved to Version > Tracker but the link there was damaged: > http://wwwmaster.postgresql.org/download/mirrors-ftp/source/v9.0.1/postgresql-9.0.1.tar.bz2 This is clearly not a bug... I have no idea what Version Tracker is, or where you got that link from, but postgresql 9.0.1 is an out of date version. You can find downloads for all current versions at http://www.postgresql.org/download/. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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 #6502: Missing Link at Version Tracker
No, I am saying it's *not* current - it is out of date, as I wrote. And that all current versions are available from http://www.postgresql.org/download/. The root of www.postgresql.org states what the current versions are. They are all available from the download site that I sent the link for. //Magnus On Sun, Mar 4, 2012 at 14:02, Ronald Hofmann wrote: > So you say 9.01 for 10.4 (from 2007) is current? > No thank you, I chose MySql > > Regards > --- > > Am 04.03.2012 um 12:44 schrieb Magnus Hagander : > >> On Fri, Mar 2, 2012 at 06:41, wrote: >>> The following bug has been logged on the website: >>> >>> Bug reference: 6502 >>> Logged by: Ronald Hofmann >>> Email address: pro...@jumbosoft.de >>> PostgreSQL version: Unsupported/Unknown >>> Operating system: MacOSX Lion >>> Description: >>> >>> I haven´t used PG for some time and since I didn´t find anything on your >>> site, only a download for 10.4. which is really old, I moved to Version >>> Tracker but the link there was damaged: >>> http://wwwmaster.postgresql.org/download/mirrors-ftp/source/v9.0.1/postgresql-9.0.1.tar.bz2 >> >> This is clearly not a bug... >> >> I have no idea what Version Tracker is, or where you got that link >> from, but postgresql 9.0.1 is an out of date version. You can find >> downloads for all current versions at >> http://www.postgresql.org/download/. >> -- 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 #6513: explain (analyze, buffers) and toasted fields
The following bug has been logged on the website: Bug reference: 6513 Logged by: Maxim Boguk Email address: maxim.bo...@gmail.com PostgreSQL version: 9.0.7 Operating system: Linux Description: I got hit by that bug when explored reasons of one very slow production query again. And I lost a lot time trying reproduce the problem query on production server with explain analyze. Finally I found I need some workaround to get explain perform actual work with toasted data. So there is going the bug report: EXPLAIN do not take into account that some result fields will require detoasting and produce wrong buffers result. Test case: pgsql=# drop table if exists test; DROP TABLE Time: 277.926 ms pgsql=# CREATE TABLE test (id integer primary key, value text); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table "test" CREATE TABLE Time: 3.812 ms --populate table with large toasted field pgsql=# INSERT INTO test select i,(select array_agg(random()) from generate_series (1,1000))::text from generate_series (1,1000) as g(i); INSERT 0 1000 Time: 3176.286 ms --wrong explain value at least for the buffers value... and whats even worse wrong (100x less that would be actual) runtime --(Buffers: shared hit=7) - wrong value pgsql=# EXPLAIN (analyze, costs, buffers) select * from test; QUERY PLAN -- Seq Scan on test (cost=0.00..10.70 rows=1000 width=36) (actual time=0.020..1.656 rows=1000 loops=1) Buffers: shared hit=7 Total runtime: 3.252 ms (3 rows) Time: 3.704 ms --again wrong pgsql=# EXPLAIN (analyze, costs, buffers) select value from test; QUERY PLAN -- Seq Scan on test (cost=0.00..10.70 rows=1000 width=32) (actual time=0.013..1.625 rows=1000 loops=1) Buffers: shared hit=7 Total runtime: 3.141 ms (3 rows) Time: 3.428 ms --force take detoasting into account via || with toasted field --result close to reality (Buffers: shared hit=4700 - real value) pgsql=# EXPLAIN (analyze, costs, buffers) select value||'a' from test; QUERY PLAN Seq Scan on test (cost=0.00..13.20 rows=1000 width=32) (actual time=0.264..187.855 rows=1000 loops=1) Buffers: shared hit=4700 Total runtime: 189.696 ms (3 rows) Time: 190.001 ms --actual timings of the both queries the same. pgsql=# \o /dev/null pgsql=# select * from test; Time: 219.845 ms pgsql=# \o /dev/null pgsql=# select value||'a' from test; Time: 221.599 ms Having correct buffer hit/read values could be critical when toasted fields are likely to be read from the HDD. -- 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 #6512: Bug with prepared statement and timestamp + interval
The following bug has been logged on the website: Bug reference: 6512 Logged by: Stefano Baccianella Email address: stefano.bacciane...@gmail.com PostgreSQL version: 9.1.1 Operating system: Windows 7 64bit Description: When trying to execute a query like: SELECT * FROM table WHERE timestamp_column > $1 AND timestamp_column < $1 + interval '1 hour' There is no problems, but when executing SELECT * FROM table WHERE timestamp_column > $1 - interval '1 hour' AND timestamp_column < $1 + interval '1 hour' The database return a error saying the the operator timestamp > interval does not exist. Either the query SELECT * FROM table WHERE timestamp_column < $1 + interval '1 hour' AND timestamp_column > $1 Does not work The $1 value is a timestamp (like now() for instance). But the query SELECT * FROM table WHERE timestamp_column = $1 OR ( timestamp_column > $1 - interval '1 hour' AND timestamp_column < $1 + interval '1 hour') works as expected. It seems that the analyzer cannot guess the value of a prepared statement combined with an interval. For my test i'm using PHP without PDO. -- 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 #6511: calling spi_exec_query from non-main package, results in: couldn't fetch $_TD
The following bug has been logged on the website:
Bug reference: 6511
Logged by: Mark Murawski
Email address: ma...@kobaz.net
PostgreSQL version: 9.1.3
Operating system: Linux - Debian Squeeze postgres 9.1 from backports
Description:
create table mytable ( id integer );
--
CREATE OR REPLACE FUNCTION mytrigger() RETURNS trigger AS $BODY$
return undef
$BODY$ LANGUAGE plperlu VOLATILE COST 100;
--
CREATE TRIGGER "insert" BEFORE INSERT ON mytable FOR EACH ROW EXECUTE
PROCEDURE mytrigger();
--
CREATE OR REPLACE FUNCTION myfunc() RETURNS text AS $BODY$
package foo;
sub foo {
main::spi_exec_query(q{INSERT INTO mytable VALUES (1) RETURNING id});
};
package main;
foo::foo();
return;
$BODY$ LANGUAGE plperlu VOLATILE COST 100;
--
pbx=# select * from myfunc();
ERROR: couldn't fetch $_TD at line 4.
CONTEXT: PL/Perl function "myfunc"
-- this works:
CREATE OR REPLACE FUNCTION myfunc() RETURNS text AS $BODY$
package foo;
sub foo {
package main;
spi_exec_query(q{INSERT INTO mytable VALUES (1) RETURNING id});
};
package main;
foo::foo();
return;
$BODY$ LANGUAGE plperlu VOLATILE COST 100;
select * from myfunc();
myfunc
(1 row)
drop table mytable;
drop function mytrigger();
drop function myfunc();
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
