[BUGS] unsubscribe me
pls unsubscribe me .. from the list ... if anybody having doubts sending mails [EMAIL PROTECTED] i am receiving i tried to block it but in vain pls unsunscribe from that mailing list __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ---(end of broadcast)--- TIP 3: 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
[BUGS] i need help
hi i got a problem with postgresql i install the pgsql like you said on the help file and when i try to create a db (database) it always give me that error: psql: FATAL 1: cannot open /usr/local/pgsql/data/global/1262: Permission denied createdb: database creation failed and i do all what you said on the help file: ./configure gmake su gmake install adduser postgres mkdir /usr/local/pgsql/data chown postgres /usr/local/pgsql/data su - postgres /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1 & /usr/local/pgsql/bin/createdb test Pls help me !! [EMAIL PROTECTED] _ Rejoignez le plus grand service de messagerie au monde avec MSN Hotmail. http://www.hotmail.com/fr ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] A bug in gist code with fetch/move
POSTGRESQL BUG REPORT TEMPLATE
Your name : Dima Tkach
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : pentium
Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.12-20
PostgreSQL version (example: PostgreSQL-7.2.1): PostgreSQL-7.2.1
Compiler used (example: gcc 2.95.2) : egcs-2.91.57
Please enter a FULL description of your problem:
Move/fetch doesn't work correctly with cursors for queries that use GiST
indexes:
If you declare such a cursor, fetch a few rows, move it back the same number
of rows and fetch again, the output will start with the SECOND row, not the
first one.
Similarly, if you 'fetch all' from the cursor, and then 'fetch -1', you will
get the one BEFORE the last row, not the last one.
The problem is specific to GiST - it does not occur with btree or seq scan
(I did not test rtrees though) - but it is NOT related to any particular
extension. I ran into it with my own (custom) extension, and then reproduced
the same problem using btree_gist from contrib...
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
This example uses btree_gist implementation from contrib, but the same problem
will occur with any GiST extension, as far as I know:
-- START OF EXAMPLE (run it in psql)
\i contrib/btree_gist.sql
create table test (x int);
insert into x values (1);
insert into x values (2);
create index test_idx on test using gist (x gist_int4_ops);
set enable_seqscan = false;
begin;
declare test_cursor cursor for select * from test where x > 0;
fetch 1 from test_cursor;
move -1 in test_cursor;
-- PROBLEM HERE:
-- The following command will return 2, although the correct output is 1
fetch 1 from test_cursor;
-- Or (it is actually, the same problem):
declare test_cursor cursor for select * from test where x > 0;
fetch all from test_cursor;
-- PROBLEM: This returns 1, but it should be 2
fetch -1 from test_cursor;
commit;
-
-- AND HERE IS THE CORRECT BEHAVIOR:
-
drop index test_idx;
begin;
declare test_cursor cursor for select * from test where x > 0;
fetch 1 from test_cursor;
move -1 in test_cursor;
fetch 1 from test_cursor; -- Returns 1 (CORRECT)
declare test_cursor cursor for select * from test where x > 0;
fetch all from test_cursor;
fetch -1 from test_cursor; -- Returns 2 (ALSO CORRECT)
commit;
-- END OF EXAMPLE
If you know how this problem might be fixed, list the solution below:
-
I compared the gist code to btree, and it seems to me that the patch below
should do the job (I did compile it and verified that it fixes the problem):
*** gistget.c Wed Apr 3 16:31:08 2002
--- gistget.c.old Wed Apr 3 16:29:08 2002
***
*** 164,173
ReleaseBuffer(b);
if (so->s_stack == (GISTSTACK *) NULL)
- {
- ItemPointerSetInvalid (&(s->currentItemData));
return (RetrieveIndexResult) NULL;
- }
stk = so->s_stack;
b = ReadBuffer(s->relation, stk->gs_blk);
--- 164,170
I hope, it helps...
Dima
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[BUGS] Bugs report
Hi I have installed a 7.1.3 postgresql version on my linux server. When I type "createuser " it asks me : Shall the new user allowed to create databases (y/n)? Shall the new user allowed to create more new user (y/n)? I answer yes to the both questions and then a bug report said : " psql : connetDbstart() -- connect() failed - no such file or directory Is the postmaster running locally and accepting connections on Unix socket :'/tmp/.s.PSQL.5432' createuser : creation of user 'xxx' failed. Thanks for your help. Mr Paquin
[BUGS] a problem with case in psql
I've used pgAccess to make all the tables and colums. Ex.: table diagnosis column diagnosis_ID Then, when I use psql to execute select statements, diagnosis_ID does not exist. But when I change the column name to diagnosis_id it works fine. The problem is therefore that it is possible to create a column name with uppercase but psql transforms all statements to lowercase, and therefore will not work. (Sorry about my bad English) Øystein Thorsen Norwegian student ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] a problem with case in psql
On Wed, 3 Apr 2002, Øystein Thorsen wrote: > I've used pgAccess to make all the tables and colums. > Ex.: table diagnosis column diagnosis_ID > > Then, when I use psql to execute select statements, diagnosis_ID does > not exist. > > But when I change the column name to diagnosis_id it works fine. > > The problem is therefore that it is possible to create a column name > with uppercase but psql transforms all statements to lowercase, and > therefore will not work. It probably means that pgAccess is double quoting the identifier for you on creation, in which case you should (and must if the identifier is mixed case) always refer to it in double quotes. If the identifier wasn't double quoted at creation time it would have been case folded to lowercase as well. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] Bug #629: "for ... select ... loop" repeat first 9 rows
Michael V. Reztsov ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
"for ... select ... loop" repeat first 9 rows
Long Description
Hello!
Sorry for bad English.
PostgreSQL 7.2, Redhat Linux 7.1
Problem:
In pl/pgsql, when table has 9 or less records, iterating through simple
"select * from table" with simultaneously update gives normal results.
But if table has 10 and more records, iterating repeat first 9 rows.
If "select" statement contains "order by", iterating gives normal results
with any rows amount.
Test:
1. createdb testdb
2. psql testdb
3. \i bugtest.pgsql -- example code
4. SELECT bugtest();
5. INSERT INTO groups VALUES ('group10');
6. SELECT bugtest();
7. In "bugtest" function, comment first "for ... loop" line, uncomment second "for ...
loop" line
8. \i bugtest.pgsql
9. SELECT bugtest();
10. INSERT INTO groups VALUES ('group10');
11. SELECT bugtest();
Sample Code
DROP TABLE groups;
CREATE TABLE groups (
groupname text,
rel_id integer
);
COPY "groups" FROM stdin;
group01 \N
group02 \N
group03 \N
group04 \N
group05 \N
group06 \N
group07 \N
group08 \N
group09 \N
\.
DROP FUNCTION bugtest();
CREATE FUNCTION bugtest() RETURNS BOOLEAN AS '
DECLARE
_group RECORD;
_count INTEGER;
i INTEGER := 0;
BEGIN
SELECT count(*) into _count from groups;
FOR _group IN SELECT * FROM groups LOOP -- buggy without "ORDER BY"
--FOR _group IN SELECT * FROM groups ORDER BY groupname LOOP -- normal
i := i + 1;
raise notice ''N. = %, name = %'', i, _group.groupname;
UPDATE groups SET rel_id = 1 WHERE groupname = _group.groupname;
END LOOP;
RETURN i = _count;
END;
' LANGUAGE 'PLPGSQL';
No file was uploaded with this report
---(end of broadcast)---
TIP 3: 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 #629: "for ... select ... loop" repeat first 9 rows
[EMAIL PROTECTED] writes: > "for ... select ... loop" repeat first 9 rows This is fixed in 7.2.1 --- at least, I don't see anything wrong when trying your example. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
