Re: [BUGS] BUG #1312: the ordinal 2821 could not be located
Hi Magnus,
I had the same problem, and your answer helped me to get PostGreSQL
finally installed by removing the existing LIBEAY32.DLL.
As far as I could find out, my LIBEAY32.DLL had been installed by
CrystalReports 10 and it has the version number 0.9.6.101, a size of
657 KB and the date of the last changes is 09th of December 2003.
Obviously it is not replaced during the installation process although
the installation file is newer (but without visible version number).
After having installed the new dll file CrystalReports does not seem
to have any problem but maybe I'm not using any of the features
provided by this file.
Thanks for your help, maybe my informations can be useful.
Regards
Roland
[EMAIL PROTECTED] ("Magnus Hagander") wrote in message news:<[EMAIL
PROTECTED]>...
> > The following bug has been logged online:
> >
> > Bug reference: 1312
> > Logged by: Amie
> >
> > Email address: [EMAIL PROTECTED]
> >
> > PostgreSQL version: 8.0 Beta
> >
> > Operating system: windows 2000 prof
> >
> > Description:the ordinal 2821 could not be located
> >
> > Details:
> >
> > At the point when the installer issues initdb.exe I get the
> > above mentioned "LIBEAY32.dll" error.
> >
> > The initdb.log file is empty.
> >
> > I downloaded "postgresql-8.0.0-beta4.zip".
>
> Seems you have a conflicting version of LIBEAY32.dll in your system32
> directory. What version do you have there? ANd do you know where it
> comes from?
>
> //Magnus
>
>
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] BUG #1668: Problem with download 8.0.3 - probably invalid zip
The following bug has been logged online: Bug reference: 1668 Logged by: Roland Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Win 2000 Description:Problem with download 8.0.3 - probably invalid zip Details: Hi, I try to download newest PostgreSQL installation for Windows (postgresql-8.0.3.zip) but I still have a problem with unzip it (there is message: "Cannot open file: it does not appear to be a valid archive. If you downloaded this file, try downloading the file again." ). I try from different mirrors (Poland, US, Germany, Russia, Nederland, etc.) and from different ISP but problem is still the same (with postgresql-8.0.3-binaries-no-installer.zip there is no such a problem). Maybe zip file is damaged cause I can't believe that I still have a problem with this one file :-( Regards, Roland ---(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] Need some help: attlen is pg_attributes gives a negative value.. .
>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes: Tom> "Klein, Robert" <[EMAIL PROTECTED]> writes: >> [ attlen for a char(n) field is -1 ] >> I know in previous versions the length as defined in the create >> table statement was given. Any ideas? Tom> Must have been quite a few versions back; attlen has been -1 Tom> for variable-length datatypes for as long as I've been paying Tom> attention. (Of course char(n) isn't *really* variable length, Tom> but it's treated that way so that the representation is the Tom> same as for varchar(n) and text.) When did this change? I haven't looked 6.5, but I thought 6.3 still has bpchar as fixed length and char(n) was blank padded whereas varchar was not. roland -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhDUnix Software Solutions [EMAIL PROTECTED] 76-15 113th Street, Apt 3B [EMAIL PROTECTED] Forest Hills, NY 11375
[BUGS] RPM buglet, postgres-devel
-BEGIN PGP SIGNED MESSAGE- First, I built from the 7.0.2 source RPM. This RPM seems to have installed /usr/lib/pgsql/os.h as a symlink to .././include/port/linux.h which doesn't exist. roland - -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhDUnix Software Solutions [EMAIL PROTECTED] 76-15 113th Street, Apt 3B [EMAIL PROTECTED] Forest Hills, NY 11375 -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQCVAwUBOYmue+oW38lmvDvNAQG6wwP/W4tBCi8WdyG/4Rf2SZsclnw4q/HyyTQU TKAUu1vQQyexNH4ZEHrm1pkhLldIceonEGZLR6k+Qyv/t4uYAB1Tg8rNggB3PCvK LpJkC0iD6KztNCEdrj5en8DOkSZ6bbcpjmEhdyLdjOMMPr/1ed1ayfxBEhNLVQYp /G3NLl7ZpaY= =pvls -END PGP SIGNATURE-
[BUGS] RH 6.1, PostgreSQL 7.0.2, ipcclean madness
-BEGIN PGP SIGNED MESSAGE-
I have finally needed to use ipcclean. I recently built HaruspeX 4.0,
an application for managing pictures which uses Postgres, and while
asking to delete a table, it hung. I had the app in the debugger, and
I found it was hung on the database call itself. So, after waiting a
couple of hours, I decided to bounce postgres by running the init
script. HaruspeX dutifully reported that the backend had closed the
connection. However, postgres did not come back up. I found two
processes running as postgres:
532 root> ps -efw | grep post
postgres 26171 1 0 00:02 ?00:01:04 /usr/bin/postgres localhost roland
family idle
postgres 26188 1 0 00:03 ?00:00:00 /usr/bin/postgres localhost roland
family idle
root 6681 20510 0 21:20 pts/200:00:00 grep post
When I attempted to run pgctl directly, it reported a problem with
semaphore space, so I tried to run ipcclean. It kept reporting I had
a postmaster running when I couldn't find it. Finally, I had a look
at the script. Oops, it has this line:
if ps x | grep -s 'postmaster' >/dev/null 2>&1 ; then
But consider:
557 root> ps x | grep -s 'postmaster'
7084 pts/2S 0:00 grep -s postmaster
So, it keeps seeing its test instead of the real postmaster. How about
ps x | grep -s postmaster | grep -v grep
instead?
roland
- --
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhDUnix Software Solutions
[EMAIL PROTECTED] 76-15 113th Street, Apt 3B
[EMAIL PROTECTED] Forest Hills, NY 11375
-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface
iQCVAwUBOYoeLOoW38lmvDvNAQGFsAP+IHgR7bCai2W8mV9eJQvMMid29ulz4n0T
gHqVDE7hO7KWR+Lrd3KDmCQvOtEGVQazZXwp74SWBtWt1FBMUaLa8HzN3uhO4PPB
77jssDJJchC7ivNo49cxkRu+rCDK/u0GX7iw+sZQSHWwgQnzx69+9/XmhLkT3bUp
e8LkSp7jly8=
=kwCA
-END PGP SIGNATURE-
[BUGS] UNION and VIEW
Your name : Roland Schulz Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium MMX Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.1 ELF PostgreSQL version (example: PostgreSQL-7.1): PostgreSQL-7.1beta4 Compiler used (example: gcc 2.8.0) : 2.95.2 Please enter a FULL description of your problem: When using UNION in a VIEW, the view displays always all records disregarding any WHERE's. This problem didn't happen with beta1. The SELECT in the example should only display the records where the field 'typ' is 1 not all records. create database test; \connect test CREATE TABLE "t2" ( "nr2" integer, "t1" integer ); CREATE TABLE "t1" ( "nr1" integer, "typ" integer, "art" integer ); CREATE VIEW "feld" as SELECT * FROM t1, t2 WHERE t1.nr1 = t2.t1 UNION SELECT *, null, null FROM t1 WHERE t1.art = 1; insert into t2 values(4,4); insert into t2 values(3,3); insert into t1 values(1,1, 1); insert into t1 values(2,2, 1); insert into t1 values(3,1, 2); insert into t1 values(4,2, 2); select * from feld where typ=1; \c drop database test;
[BUGS] BUG #3005: please help
The following bug has been logged online: Bug reference: 3005 Logged by: roland diaz Email address: [EMAIL PROTECTED] PostgreSQL version: 6 Operating system: linux Description:please help Details: hello why i cant crate a table in postgress ---(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
[BUGS] Pg_dump uses up RAM and swap space
Hi! Reading the archives I understand this is a problem of postgres version prior 7.1, and I'm experiencing the very same error as Steve Riley reported last month. I saw that the suggestion was to use 7.2, but I'm not sure you meant dump 7.1 database from 7.1 backend using 7.2 pg_dump. We have approx. 1.5 Gb of data in a 7.1 database, and would not like to loose it, but cannot dump it with 7.1. If this is the way to go, please confirm that. Thank you for your time. Roland Szabo ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Pg_dump uses up RAM and swap space
Hi! Reading the archives I understand this is a problem of postgres version prior 7.1, and I'm experiencing the very same error as Steve Riley reported last month. I saw that the suggestion was to use 7.2, but I'm not sure you meant dump 7.1 database from 7.1 backend using 7.2 pg_dump. We have approx. 1.5 Gb of data in a 7.1 database, and would not like to loose it, but cannot dump it with 7.1. If this is the way to go, please confirm that. Thank you for your time. Roland Szabo ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] ecpg Oracle compatibility issue
Hello together,
While porting my TPC-C implementation from Oracle, I discovered the
attached problem with the EXEC SQL COMMIT RELEASE statement.
Bye,
Roland
POSTGRESQL BUG REPORT TEMPLATE
Your name : Roland Karch
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.19
PostgreSQL version (example: PostgreSQL-7.3): PostgreSQL-7.3
Compiler used (example: gcc 2.95.2) : gcc 2.95.4
Please enter a FULL description of your problem:
The Embedded SQL parser ecpg produces corrupt code for the statement
COMMIT RELEASE;
It results in the error code -220 - no such connection.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
Source code tst.pc:
---
EXEC SQL INCLUDE sqlca;
int
main(int argc, char** argv) {
EXEC SQL CONNECT TO test USER test IDENTIFIED BY test;
EXEC SQL COMMIT RELEASE;
EXEC SQL DISCONNECT;
}
---
This results in this C file (excerpt):
---
int
main(int argc, char** argv) {
{ ECPGconnect(__LINE__, "test" , "test" , "test" , NULL, 0); }
#line 5 "tst.pc"
ECPGtrans(__LINE__, NULL, "commit");
#line 6 "tst.pc"
ECPGdisconnect(__LINE__, "");
#line 6 "tst.pc"
{ ECPGdisconnect(__LINE__, "CURRENT");}
#line 7 "tst.pc"
}
If you know how this problem might be fixed, list the solution below:
-
Maybe the following patch helps - unfortunately, I wasn't able to get bison to
run with your makefile in my environment, so it is totally untested:
--- postgresql-7.3/src/interfaces/ecpg/preproc/preproc.y.orig Fri Nov 1 23:52:33
2002
+++ postgresql-7.3/src/interfaces/ecpg/preproc/preproc.yMon Dec 9 17:41:30
+2002
@@ -4709,7 +4709,9 @@
fprintf(yyout, "ECPGtrans(__LINE__, %s, \"%s\");",
connection ? connection : "NULL", $1);
whenever_action(0);
- fprintf(yyout, "ECPGdisconnect(__LINE__, \"\");");
+ fprintf(yyout, "ECPGdisconnect(__LINE__, \"%s\");",
+ connection ?
+ connection : "\"CURRENT\"");
whenever_action(0);
free($1);
}
---(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] ecpg Oracle compatibility issue
On Thu, Dec 12, 2002 at 04:49:30PM -0500, Bruce Momjian wrote: > I applied the attached patch. Your version looked like it would have > doubled the double-quotes. Oops - yes, I got that wrong. > As you mentioned, you couldn't get bison to > work, so you weren't able to test it. Please look over this patch and > make sure it is correct. It works fine, just got bison to work on my other computer. > Also check the other use of ECPGdisconnect(). > Is that correct? Does it need "CURRENT"? Yes, it's needed. Supplying a NULL pointer instead results in a segfault for me. However, it would work if src/interfaces/ecpg/lib/connect.c line 468 was patched - checking for NULL before dereferencing a user-supplied pointer is generally a good idea. ---(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] BUG #1240: memory leak in JDBC driver build 215
Fabien COELHO schrieb:
328 [main] DEBUG com.mosaicag.rwa.dbutil.standard.DefaultCsvExport -
executing SQL-Stmt: SELECT * FROM transaction WHERE transaction_date >=
to_timestamp('01.01.2002', 'DD.MM.') AND transaction_date <
to_timestamp('01.01.2003', 'DD.MM.')
java.lang.OutOfMemoryError
Exception in thread "main"
Maybe the JDBC drivier tries to allocate the whole result of the query?
If so, it is not a memory leak, it's a big memory need;-)
You might try using a cursor manually (well, if it is the problem,
then it just shows that jdbc should do it by default).
Using a cursor avoids the out of memory error. I used:
stmt.setFetchSize(1000);
after creation of the statement now.
Thanks, that helped. But for me this behaviour is still a bug.
--
Roland Walter
MOSAIC SOFTWARE AG
Telefon: 02225/882-411 Fax: 02225/882-201
http://www.mosaic-ag.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
Re: [BUGS] Problem with Upper/Lower Function
Hello,
Hesse, Hendrik schrieb am 16.12.2004 16:41:
I fond a problem at the RC1 of PostgreSQL (W32 - Version)
When you use the UPPER or LOWER function with German letters (ä,ö,ü) this
letters stay in lower/upper case.
You can reproduce this error with this simple examples:
select upper('ü');
select upper('Tüte');
Test
ID | sText
---
1 | TÜTE
2 | EIMER
select * from Test where sText = upper('tüte');
I can reproduce this problem in several computers.
right now you can only use database encoding "LATIN1" (without
euro-sign) or "LATIN10" for german text. "UNICODE" doesn't work with
umlauts, sharp s or euro-sign.
Because of missing conversion functions to win1252 (Windows default
encoding on german MS systems) you must use same encoding on client side
as for the database, or UNICODE on client side, if your
application supports it.
I prepared a patch for WIN1252 encoding on db and client side, which
will probably be included in version 8.1 (V8.0 is closed for new features).
An alternative is to use an encoding for the database, which you
normally don't use (e.g. WIN1250) in conjunction with a patched
conversion DLL (e.g. utf8_and_win1250.dll), so you can use either
WIN1250 (which represents WIN1252) or UNICODE on client side. This way I
do it until real WIN1252-support is available.
With best regards,
Roland.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
