[BUGS] BUG #1368: initdb fails
The following bug has been logged online: Bug reference: 1368 Logged by: Michiel Tas Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: W XP Home Description:initdb fails Details: I am using FAQ_CYGWIN.txt but when I follow all instructions precisely, and perform the database initialisation as follows: initdb -D /usr/local/pgsql/data -W -E LATIN1 the result is "initdb: failed". So first of all, is all documentation still up to date? Second of all, is there a workaround or some other solution for this problem? Third of all, "initdb:failed" is the kind of error that is too general. It does not provide a clue of what the problem is and how to solve it. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] Wrong messages running on Windows
Hi! I've been using the PostgreSQL database in Windows since the Beta2-dev3, and it had a bug I didn't report. I've just downloaded the rc2, and uninstalled my previous version, and installed the newest one, and it still have the same bug. When executing the command line functions psql, pg_dump, createuser, createdb, dropuser, dropdb, they output a message in the format: could not find a "functionname" to execute where functionname is the name of the function i'm using. Hope you can help me with this "bug" (if it is), so PostgreSQL can continue improving. Thanks a lot. Regards, Elvis E. Henríquez A. P.S.: I'm running Windows 2000 Professional with Service Pack 4, with all critical updates installed. My OS version is in Spanish (and most of my software too). My computer is an Intel Celeron 600 MHz, 256 MB RAM, 40 GB HDD (with 4 partitions, all in NTFS).
[BUGS] BUG #1370: Problem with arrays in PL/PGSQL
The following bug has been logged online:
Bug reference: 1370
Logged by: David Bowen
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Fedora Core 2/Athlon 950 processor
Description:Problem with arrays in PL/PGSQL
Details:
PostgreSQL 8.0.0rc2
test=# \d scores
Table "public.scores"
Column | Type | Modifiers
---+-+---
contestant_id | integer |
category | integer |
score | integer |
test=# select * from scores;
contestant_id | category | score
---+--+---
1 |1 |70
1 |2 |73
1 |3 |69
2 |1 |72
2 |2 |70
2 |3 |73
3 |1 |66
3 |2 |75
3 |3 |72
(9 rows)
test=# \i /home1/dmb/crosstab
CREATE FUNCTION
test=# select crosstab(1);
ERROR: array value must start with "{" or dimension information
CONTEXT: PL/pgSQL function "crosstab" line 5 at block variables
initialization
$ cat /home1/dmb/crosstab
CREATE OR REPLACE FUNCTION crosstab (integer) RETURNS integer[] AS '
DECLARE
contestant ALIAS FOR $1;
row scores%ROWTYPE;
s integer[3]:= (-1,-1,-1);
BEGIN
FOR row IN SELECT * FROM scores where contestant_id = contestant LOOP
s[row.category] := row.score;
END LOOP;
RETURN s;
END;
' LANGUAGE 'PLPGSQL';
Changing
s integer[3]:= (-1,-1,-1);
to
s integer[3]:= {-1,-1,-1};
test=# \i /home1/dmb/crosstab
CREATE FUNCTION
test=# select crosstab(1);
ERROR: syntax error at or near "{" at character 9
QUERY: SELECT {-1,-1,-1}
CONTEXT: PL/pgSQL function "crosstab" line 5 at block variables
initialization
LINE 1: SELECT {-1,-1,-1}
^
Changing to
s integer[3];
test=# \i /home1/dmb/crosstab
CREATE FUNCTION
test=# select crosstab(1);
crosstab
--
(1 row)
gdb shows exec_assign_value returning at line 3137 because oldarrayisnull is
TRUE, so s never gets assigned. If you need additional information, ask and
ye shall receive.
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[BUGS] rule system re-evaluates expressions
The rule-system seems to evaluate a functional value
of a column anew. Please confim if this is a
documented/intentional behaviour of the rule system?
The order of evaluation of the expresion(s) within
original statemant and rule differ between "on insert"
and "on update" rules.
For details see the following artificial example
logging actions on "tbl" to "log" and using nextval as
an expression (code and output below). As a result the
columns tbl.id and log.id differ, unexpectedly, by
+-1.
regards, Jan
=== SQL
-- EXAMPLE: rule-system revaluates
-- the functionale expressions
CREATE sequence sq ;
CREATE table tbl (
id integer default nextval('sq'),
da char(1) default '-',
ts timestamp default now() );
-- log=tbl without defaults
CREATE table log (
id integer,
da char(1),
ts timestamp );
-- rules for logging actions on "tbl" to "log"
CREATE rule tblog1 AS ON INSERT TO tbl
do insert INTO log (id,da,ts)
values (NEW.id, NEW.da, NEW.ts);
CREATE rule tblog2 AS ON UPDATE TO tbl
do insert INTO log (id,da,ts)
values (NEW.id, NEW.da, NEW.ts);
-- inserts/updates using defaul values
-- using default id :
insert into tbl (da) values ('a');
-- using default id :
insert into tbl (da) values ('b');
-- using explicit expression for id :
insert into tbl (id,da) values (nextval('sq'),'c');
-- using explicit fixed id :
insert into tbl (id,da) values (0,'d');
-- using an expressional but explicit id
update tbl set id=nextval('sq') where id=0;
-- As a result the columns tbl.id and log.id
-- differ by one :
select * from tbl;
select * from log;
-- drop
drop table tbl cascade;
drop table log cascade;
drop sequence sq;
OUTPUT
=# select * from tbl;
id | da | ts
++
1 | a | 2004-12-14 11:15:21.996594
3 | b | 2004-12-14 11:15:22.002465
5 | c | 2004-12-14 11:15:22.00822
8 | d | 2004-12-14 11:15:22.012329
(4 rows)
=# select * from log;
id | da | ts
++
2 | a | 2004-12-14 11:15:21.996594
4 | b | 2004-12-14 11:15:22.002465
6 | c | 2004-12-14 11:15:22.00822
0 | d | 2004-12-14 11:15:22.012329
7 | d | 2004-12-14 11:15:22.012329
(5 rows)
---(end of broadcast)---
TIP 8: explain analyze is your friend
[BUGS] Wrong messages running on Windows - Part 2
Sorry, I forgot to say that functions output that string, but the function executes perfectly. For example: createdb -U kuaimare dbkuaima could not find a "createdb" to execute Password: CREATE DATABASE And the database (or the query, or the data dump, etc.) executes perfectly, but with the string: could not find a "functionname" to execute withing the function execution output. - Mensaje original - De: Elvis E. Henriquez A. Para: pgsql-bugs@postgresql.org Enviado: Jueves, 30 de Diciembre de 2004 23:45 Asunto: Wrong messages running on Windows Hi! I've been using the PostgreSQL database in Windows since the Beta2-dev3, and it had a bug I didn't report. I've just downloaded the rc2, and uninstalled my previous version, and installed the newest one, and it still have the same bug. When executing the command line functions psql, pg_dump, createuser, createdb, dropuser, dropdb, they output a message in the format: could not find a "functionname" to execute where functionname is the name of the function i'm using. Hope you can help me with this "bug" (if it is), so PostgreSQL can continue improving. Thanks a lot. Regards, Elvis E. Henríquez A. P.S.: I'm running Windows 2000 Professional with Service Pack 4, with all critical updates installed. My OS version is in Spanish (and most of my software too). My computer is an Intel Celeron 600 MHz, 256 MB RAM, 40 GB HDD (with 4 partitions, all in NTFS).
[BUGS] Tsearch2 ispell parser unicode bug ?
Hi
I'm using tsearch2 since postgresql-7.4.0 without problems with UTF-8
(yes i know about tolower() problems in postgresql < 8).
I tried postgresql-8.0beta and rc (up to rc3) and all versions contains
bug in tsearch2. (probably in ispell code part)
I can set up tsearch without problems for unicode fulltext (for czech
language), but when i tried the test command like this (and some
similars).
SELECT lexize('cz_ispell','jablkÅm');
postgresql fails with SIG11.
I tried to backport the ispell part and it works without problems.
MOJE
--
Konir Tomas
Czech Republic
Brno
ICQ 25849167
---(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] rule system re-evaluates expressions
jan pfaler <[EMAIL PROTECTED]> writes: > The rule-system seems to evaluate a functional value > of a column anew. Please confim if this is a > documented/intentional behaviour of the rule system? Yes. > The order of evaluation of the expresion(s) within > original statemant and rule differ between "on insert" > and "on update" rules. Order of evaluation is never guaranteed. Generally it's better to use triggers for the sort of problem you show here. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1370: Problem with arrays in PL/PGSQL
On Mon, Jan 03, 2005 at 03:11:05AM +, David Bowen wrote:
> test=# select crosstab(1);
> ERROR: array value must start with "{" or dimension information
> CONTEXT: PL/pgSQL function "crosstab" line 5 at block variables
> initialization
> $ cat /home1/dmb/crosstab
> CREATE OR REPLACE FUNCTION crosstab (integer) RETURNS integer[] AS '
> DECLARE
> contestant ALIAS FOR $1;
> row scores%ROWTYPE;
> s integer[3]:= (-1,-1,-1);
See "Array Value Input" in the "Arrays" section of the "Data Types"
chapter in the documentation; see also "Array Constructors" in the
"Value Expressions" section of the "SQL Syntax" chapter. Either
of the following should work:
s integer[3]:= ARRAY[-1,-1,-1];
s integer[3]:= ''{-1,-1,-1}'';
Since you're running 8.0, consider using dollar quotes around the
function body if backward compatibility isn't necessary -- that way
you don't have to escape single quotes that are inside the function.
See "Dollar-Quoted String Constants" in the "SQL Syntax" chapter.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] More SSL questions..
Did we ever find the solution to this, or did anyone find the cause? --- T.J. wrote: > Having some problems (still, hehe) getting SSL to work properly on > windows in the new 8.0 (all vers) environment (where cert/key is required). > > On the client side when not finding the certificate/key psql would > report the SSL error sslv3 alert handshale failure. After I figured out > where psql was looking for the files and placing them there I now get > the error: SSL SYSCALL error: Connection reset by peer > (0x2746/10054). On the server side it still reports that the peer > did not return a certificate. > > I am able to connect to the server just fine using the same > certificate/key on a linux machine...so I'm guessing it's just another > good ol' windows issue? :) > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] rule-system revaluates the functionale expressions
Thanks Tom, Refering to your answer: The syntax "NEW.column" seems to hint rather to "the new value" of column as opposed to "the expression for the new value", c.f. "OLD.column". The fact that the order of evaluation changes underlines the inconsistency; the order of evaluation would not matter in the former case. Hence, perhaps a note could be added to the documentation (did not yet find anything on it)? E.g. in "34.3. Rules on INSERT, UPDATE, and DELETE" one could add "Note that NEW.column may be re-evaluated at a new reference. This causes expressions having side-effects, notably nextval(), potentially to obtain differing values at each reference." Anyhow, postgres (community) deserves at least my gratitude for its consistency and coherence in realisation. Thanks you for a quick answer. I will look into the trigers. Regards, Jan ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1369: RC3 Compilation fails on mingw
Yeah, I redownloaded and tried again with no problems...weird...sorry for the false positive ;) Magnus Hagander wrote: I just rebuilt RC3 from scratch without any problems on MingW. I don't see any problems. The paths it's complaining about should be in src/port/pg_config_paths.h, and this file should automatically be rebuilt. Check if it's corrupted, and try removing it and rebuild that directory (first, then the ecpg dir that is failing). //Magnus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of T.J. Sent: den 2 januari 2005 03:26 To: pgsql-bugs@postgresql.org Subject: [BUGS] BUG #1369: RC3 Compilation fails on mingw The following bug has been logged online: Bug reference: 1369 Logged by: T.J. Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows XP Description:RC3 Compilation fails on mingw Details: Tested RC2 and RC3 --with-openssl configured. RC2 makes and installs fine. RC3, however, has this to say when trying make: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wold-style-definition -Wendif-labels -fno-strict-aliasing -DFRONTEND -I../.. /../../src/interfaces/ecpg/include -I../../../../src/interfaces/libpq -I../../../../src/port -I../../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../../../src/include/port/win32" -DBUILDING_DLL -c -o path.o path.c path.c: In function `get_share_path': path.c:375: error: `PGSHAREDIR' undeclared (first use in this function) path.c:375: error: (Each undeclared identifier is reported only once path.c:375: error: for each function it appears in.) path.c:375: error: `PGBINDIR' undeclared (first use in this function) path.c: In function `get_etc_path': path.c:384: error: `PGBINDIR' undeclared (first use in this function) path.c: In function `get_include_path': path.c:393: error: `INCLUDEDIR' undeclared (first use in this function) path.c:393: error: `PGBINDIR' undeclared (first use in this function) path.c: In function `get_pkginclude_path': path.c:402: error: `PKGINCLUDEDIR' undeclared (first use in this function) path.c:402: error: `PGBINDIR' undeclared (first use in this function) path.c: In function `get_includeserver_path': path.c:411: error: `INCLUDEDIRSERVER' undeclared (first use in this function) path.c:411: error: `PGBINDIR' undeclared (first use in this function) path.c: In function `get_lib_path': path.c:420: error: `LIBDIR' undeclared (first use in this function) path.c:420: error: `PGBINDIR' undeclared (first use in this function) path.c: In function `get_pkglib_path': path.c:429: error: `PKGLIBDIR' undeclared (first use in this function) path.c:429: error: `PGBINDIR' undeclared (first use in this function) path.c: In function `get_locale_path': path.c:438: error: `LOCALEDIR' undeclared (first use in this function) path.c:438: error: `PGBINDIR' undeclared (first use in this function) make[4]: *** [path.o] Error 1 make[4]: Leaving directory `/c/postgresql-8.0.0rc3/src/interfaces/ecpg/ecpglib' make[3]: *** [all] Error 2 make[3]: Leaving directory `/c/postgresql-8.0.0rc3/src/interfaces/ecpg' make[2]: *** [all] Error 2 make[2]: Leaving directory `/c/postgresql-8.0.0rc3/src/interfaces' make[1]: *** [all] Error 2 make[1]: Leaving directory `/c/postgresql-8.0.0rc3/src' make: *** [all] Error 2 ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] More SSL questions..
Not to my knowledge. By the way, for future reference on windows it looks for the cert/key in the linux equivalent of `pwd`/.postgresql/postgresql.crt/key, instead of $HOME/.postgresql/postgresql.crt/key. Maybe you already knew this but I had to do testing to figure it out so hopefully that bit of knowledge will be of use to someone else :) I tried looking through the source myself for the cause of this problem but I guess there's a reason my perl is so sharp and c so rusty these days.. Don't know if it makes much difference but I have built with vcwin and mingw with the same resulting error. Bruce Momjian wrote: Did we ever find the solution to this, or did anyone find the cause? --- T.J. wrote: Having some problems (still, hehe) getting SSL to work properly on windows in the new 8.0 (all vers) environment (where cert/key is required). On the client side when not finding the certificate/key psql would report the SSL error sslv3 alert handshale failure. After I figured out where psql was looking for the files and placing them there I now get the error: SSL SYSCALL error: Connection reset by peer (0x2746/10054). On the server side it still reports that the peer did not return a certificate. I am able to connect to the server just fine using the same certificate/key on a linux machine...so I'm guessing it's just another good ol' windows issue? :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(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] More SSL questions..
"T.J." <[EMAIL PROTECTED]> writes: > Not to my knowledge. By the way, for future reference on windows it > looks for the cert/key in the linux equivalent of > `pwd`/.postgresql/postgresql.crt/key, instead of > $HOME/.postgresql/postgresql.crt/key. Actually, it asks getpwuid() for the user's home directory, rather than looking for an environment variable named HOME. See client_cert_cb() in fe-secure.c. This could probably be documented better, but I'm not sure how. The average user is even less likely to be familiar with getpwuid() than $HOME, so it doesn't seem like referencing that library function is much of an improvement. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
