[BUGS] BUG #2197: PostgreSQL error- 'could not read block 0 of relation'
The following bug has been logged online: Bug reference: 2197 Logged by: Sunil Basu Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows 2000 Server Description:PostgreSQL error- 'could not read block 0 of relation' Details: I am running a application in Delphi7 which connects to postgreSQL database. At the time of insertion I got an error message as given below: PostgreSQL Error Code: (1) Error: could not read block 0 of relation 1663/17419/17482: Invalid argument Please help. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2195: log_min_messages crash server when in DEBUG3 to 5
Tom Lane writes: > "Jaime Casanova" <[EMAIL PROTECTED]> writes: >> in my machine (win xp) i was trying to start psql (8.1.1) with >> log_min_messages to debug5 (just to see the messages :) but even the >> service start i cannot use psql nor pgadmin i receive an error of >> server closed the connection unexpectedly > > Can't reproduce this on Linux using 8.1 branch tip, so either it's > Windows-specific or it's been fixed recently ... > Should be windows-specific - I can reproduce it with 8.1.2 on WinXP SP2 and I can't reproduce it with 8.1.2 on Slackware Linux 9.1 (kernel 2.6.15). By the way I have the crash report files Windows created - postgres.exe.hdmp, postgres.exe.mdmp, appcompat.txt and manifest.txt. -- Milen A. Radev ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2196: Useless RECHECK on RTREE index
The following bug has been logged online:
Bug reference: 2196
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2
Operating system: alphaev68-dec-osf5.1a
Description:Useless RECHECK on RTREE index
Details:
create table tpoints (x int, y int);
CREATE INDEX i_tpoints ON tpoints USING RTREE (box(point(x,y),
point(x,y)));
explain select * from tpoints where box '((0,0),(1,1))' && box(point(x,y),
point(x,y));
QUERY PLAN
---
Bitmap Heap Scan on tpoints (cost=1.05..10.46 rows=10 width=8)
Recheck Cond: ('(1,1),(0,0)'::box && box(point((x)::double precision,
(y)::double precision), point((x)::double precision, (y)::double
precision)))
-> Bitmap Index Scan on i_tpoints (cost=0.00..1.05 rows=10 width=0)
Index Cond: ('(1,1),(0,0)'::box && box(point((x)::double precision,
(y)::double precision), point((x)::double precision, (y)::double
precision)))
(4 rows)
The RECHECK is necessary in case of polygons, but useless in case of box
overlap.
pg_amop.amopreqcheck is correctly set to false, but the planner seems to
ignore that.
select pg_amop.* from pg_amop join pg_opclass c ON (amopclaid=c.oid) join
pg_operator op ON (amopopr=op.oid) where opcname='box_ops' and
oprname='&&';
amopclaid | amopsubtype | amopstrategy | amopreqcheck | amopopr
---+-+--+--+-
425 | 0 |3 | f| 500
2593 | 0 |3 | f| 500
(2 rows)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[BUGS] BUG #2198: Now returns always same date and time during a session
The following bug has been logged online: Bug reference: 2198 Logged by: Jacques Gollion Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.2 Operating system: Windows 2000 Description:Now returns always same date and time during a session Details: The following functions returns the first time the right date and time but when called at several date and time returns the date that was returned at the first call. To get again the right date, it is necessary do disconnect and reconnect. === CREATE OR REPLACE FUNCTION getserverdate(szdatetime_p "varchar") RETURNS "varchar" AS $BODY$ DECLARE tNow_l timestamp ; DECLARE szdatetime_l VARCHAR(128); begin szdatetime_l := '-1'; tNow_l := Now(); RAISE LOG ' tNow_l = %', tNow_l; szdatetime_l := TO_CHAR(tNow_l,'MMDDHH24MISS'); RAISE LOG ' szdatetime_l = %', szdatetime_l; return szdatetime_l; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE; ALTER FUNCTION getserverdate(szdatetime_p "varchar") OWNER TO postgres; GRANT EXECUTE ON FUNCTION getserverdate(szdatetime_p "varchar") TO public; GRANT EXECUTE ON FUNCTION getserverdate(szdatetime_p "varchar") TO postgres; GRANT EXECUTE ON FUNCTION getserverdate(szdatetime_p "varchar") TO client; GRANT EXECUTE ON FUNCTION getserverdate(szdatetime_p "varchar") TO batch; ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2203: Group by, suggested "feature"
The following bug has been logged online: Bug reference: 2203 Logged by: Robert Hostetter Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: CentOS 4.1 Description:Group by, suggested "feature" Details: I'm sure this will be considered a missing feature and not a bug, I know I would. We are converting from MySQL to PostgreSQL, which is a huge project. But one minor irritation we've noticed is the group by handling in PostgreSQL. If you group by a primary key for a table, you still have to include all the other columns you SELECT from that row, even though its guaranteed uniuqe because its a primary key. I understand requiring the other columns when you aren't guaranteed uniqueness, but in cases of a group by on a unique column you shouldn't need to include the rows, its repetitive, and makes porting harder for no reason. Also on a similar note, you can't group by any column you don't select. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2196: Useless RECHECK on RTREE index
"" <[EMAIL PROTECTED]> writes:
> Bitmap Heap Scan on tpoints (cost=1.05..10.46 rows=10 width=8)
>Recheck Cond: ('(1,1),(0,0)'::box && box(point((x)::double precision,
> (y)::double precision), point((x)::double precision, (y)::double
> precision)))
>-> Bitmap Index Scan on i_tpoints (cost=0.00..1.05 rows=10 width=0)
> Index Cond: ('(1,1),(0,0)'::box && box(point((x)::double precision,
> (y)::double precision), point((x)::double precision, (y)::double
> precision)))
> (4 rows)
> The RECHECK is necessary in case of polygons, but useless in case of box
> overlap.
You don't understand what a bitmap scan's recheck condition is for.
The above plan is correct.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] BUG #2198: Now returns always same date and time during a session
"Jacques Gollion" <[EMAIL PROTECTED]> writes: > The following functions returns the first time the right date and time but > when called at several date and time returns the date that was returned at > the first call. Please read http://www.postgresql.org/docs/8.1/static/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT > To get again the right date, it is necessary do disconnect and reconnect. A fresh transaction is sufficient. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2198: Now returns always same date and time during a session
On Mon, Jan 23, 2006 at 11:40:43AM +, Jacques Gollion wrote: > The following functions returns the first time the right date and time but > when called at several date and time returns the date that was returned at > the first call. See "Current Date/Time" in the documentation: http://www.postgresql.org/docs/8.1/interactive/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT "It is important to know that CURRENT_TIMESTAMP and related functions return the start time of the current transaction; their values do not change during the transaction. This is considered a feature: the intent is to allow a single transaction to have a consistent notion of the 'current' time, so that multiple modifications within the same transaction bear the same time stamp." "There is also the function timeofday() which returns the wall-clock time and advances during transactions." > To get again the right date, it is necessary do disconnect and reconnect. Do you have autocommit disabled? I'd guess all of your function calls are happening in the same transaction. You shouldn't have to reconnect; starting a new transaction should work. -- Michael Fuhr ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2203: Group by, suggested "feature"
Robert Hostetter wrote: > If you group by a primary key for a table, > you still have to include all the other columns you SELECT from that > row, even though its guaranteed uniuqe because its a primary key. Yes, this feature request is known as supporting functional dependencies. We're aware of it. > pAlso on a similar note, you can't group by any > column you don't select. Sure you can. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2178: NOT IN command don't work
On Tue, 2006-01-17 at 22:00 +, Daniel Afonso Heisler wrote: > But, when i run the next query, it don't return TRUE > # SELECT true WHERE 1 NOT IN (2,NULL,3); These are not bugs. The first statement is equivalent to # select true where (1 != 2) and (1 != NULL) and (1 != 3); 1 != NULL is itself NULL (not false!). Similarly, TRUE AND NULL AND TRUE evaluates to NULL, and therefore you've really written # select true where NULL; which, of course, should and does print nothing. Your second query # SELECT true WHERE 1 IN (1,2,NULL,3); is equivalent to # select true where (1=1) or (1=2) or (1=NULL) or (1=3); which should and does return true. Try these: # select 1=1 and null; # select 1=1 or null; # select 1!=1 and null; # select 1!=1 or null; For more info, google for `sql not in NULL'. You'll see references like http://www.metrokc.gov/gis/kb/Content/SQLTipNull.htm -Reece -- Reece Hart, Ph.D. [EMAIL PROTECTED], http://www.gene.com/ Genentech, Inc.650-225-6133 (voice), -5389 (fax) Bioinformatics and Protein Engineering 1 DNA Way, MS-93 http://harts.net/reece/ South San Francisco, CA 94080-4990[EMAIL PROTECTED], GPG:0x25EC91A0 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
