[BUGS] BUG: Each UNION | EXCEPT | INTERSECT query must have the same number of columns.
Your name : Jacek Konieczny Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : AMD K6-II 3DNow Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.2 ELF (PLD Distribution) PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3 Compiler used (example: gcc 2.8.0) : probably 2.95.3 Please enter a FULL description of your problem: When using query with EXCEPT clause in INSERT command sometime false "ERROR: Each UNION | EXCEPT | INTERSECT query must have the same number of columns." is generated, and the command fails. Probably default values are added to the first query before it is compared to the second one. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- CREATE TABLE tb1 ( a CHARACTER(10) DEFAULT 'abc', b CHARACTER(10)); CREATE TABLE tb2 ( a CHARACTER(10), b CHARACTER(10)); INSERT INTO tb1(b) SELECT b FROM tb2 EXCEPT SELECT b FROM tb1; If you know how this problem might be fixed, list the solution below: - I would have to check the source code... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] I can't initialize
This error ocurs when I've tried to run /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data: This database system will be initialized with username "postgres".This user will own all the data files and must also own the server process. Fixing permissions on pre-existing data directory /usr/local/pgsql/dados/Creating database system directory /usr/local/pgsql/dados//baseCreating database XLOG directory /usr/local/pgsql/dados//pg_xlogCreating template database in /usr/local/pgsql/dados//base/template1ERROR: Error: unknown type 'ame'. ERROR: Error: unknown type 'ame'. Creating global relations in /usr/local/pgsql/dados//baseERROR: Error: unknown type 'ame'. ERROR: Error: unknown type 'ame'. Adding template1 database to pg_database/usr/local/pgsql/bin/initdb: line 481: 1109 Falha de segmentação "$PGPATH"/postgres $BACKENDARGS template1 <"$TEMPFILE" initdb failed.Removing /usr/local/pgsql/dados/.rm: não foi possível remover diretório `/usr/local/pgsql/dados': Permissão negadaFailed.Removing temp file /tmp/initdb.1076./bin/nice: /usr/local/pgsql/~bin/initdb: Arquivo ou diretório não encontrado Please, I'm in a hurry. Thanks. Fernando.
[BUGS] pq_shadow
I am writing you because I am new to Postgesql and I have encountered a problem that I have not been able to solve through your doc's or mailing list. The problem is with the createuser utility. When I try to create a user I get the following error: ## [root@crescent1 root]# createuser webmaster -PEnter password for user "webmaster":Enter it again:Shall the new user be allowed to create databases? (y/n) yShall the new user be allowed to create more new users? (y/n) ypsql: FATAL 1: SetUserId: user 'root' is not in 'pg_shadow'createuser: creation of user "webmaster" failed[root@crescent1 root]# ## I would like to be able to use Postgresql (not just Mysql) but if I can not create a user I can not login to the Postgres data base. I advise me on how to fix this problem. I am using Red Hat 6.2 on a Intel based x86 with a Pentium CPU. Eric Williams
[BUGS] Please, fix!!! The backend can crash on your system!
If PostgreSQL failed to compile on your computer or you found a bug that is likely to be specific to one platform then please fill out this form and e-mail it to [EMAIL PROTECTED] To report any other bug, fill out the form below and e-mail it to [EMAIL PROTECTED] If you not only found the problem but solved it and generated a patch then e-mail it to [EMAIL PROTECTED] instead. Please use the command "diff -c" to generate the patch. You may also enter a bug report at http://www.postgresql.org/ instead of e-mail-ing this form. POSTGRESQL BUG REPORT TEMPLATE Your name : Alexis Wilke Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : trust me, doesn't matter Operating System (example: Linux 2.0.26 ELF) : trust me, doesn't matter PostgreSQL version (example: PostgreSQL-7.0): since PostgreSQL-6.5.x and still in the code Compiler used (example: gcc 2.8.0) : trust me, doesn't matter Please enter a FULL description of your problem: It crashes when pg_database is too large. This is because the index is compare to max with <= instead of <. I already fixed the bug on my system. That's at line Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- Create many database (or create/destroy the same many times). Once the pg_database is more than one page (16Kb) then it starts crashing. (may not crash on all systems, but trust me, my fix will work GREAT). If you know how this problem might be fixed, list the solution below: - Okay, so go in the following file: ./src/backend/utils/misc/database.c and move to the line #183 (V7.0.1) There, fix the for() as is: for(i = 0; i < max; i++) Why? Well, because 'i' starts at 0, therefore, you can't access the tuple number 'max'. If you look in other source files, you will quickly see that all these for() loops are starting with an index of 1 and use some special functions/macros to access the tuple data. --- [EMAIL PROTECTED] wrote: > Date: Wed, 28 Mar 2001 05:44:05 -0500 (EST) > From: [EMAIL PROTECTED] > To: Alexis Wilke <[EMAIL PROTECTED]> > Subject: Stalled post to pgsql-hackers > > Your message to pgsql-hackers has been delayed > pending approval of the list owner for > the following reason(s): > > Non-Member Submission from Alexis Wilke <[EMAIL PROTECTED]> > > > ATTACHMENT part 2 message/rfc822 > Date: Wed, 28 Mar 2001 02:28:45 -0800 (PST) > From: Alexis Wilke <[EMAIL PROTECTED]> > Subject: HUGE BUG - Please fix!!! > To: [EMAIL PROTECTED] > > Hi guys, > > I don't want to do a patch for a one character error. Yet, that's a HUGE > error and it really needs to be fixed. > > Once you have a pg_database file which is over 1 page, it CRASHES. > That's > what it did on me. Yes! I have many databases or rather, I often destroy > my databases to regenerate them from scratch (that's for me the easiest > way to do it). Because of that, the pg_database is now two pages. > > The utils/misc/database.c has a function called GetRawDatabaseInfo() > which reads that file "on its own". There is a HUGE bug in there, and > it may not always crash a system, but it really needs to be fixed. > > At line #183, you have a for() loop which looks like this (since at > least V6.5.0 and still present in V7.0.3): > > for (i = 0; i <= max; i++) > > All the other such loops start with an index of 1, not zero. And > therefore you want the <=. In this special case loop (or are all > the others special cases?!?) you need to use the following: > > for(i = 0; i < max; i++) > > Please, I know it's easier when you get a patch, but FIX IT. It's > not fun to try to access your database and have the backend crash > because of such a tiny bug! > > Thank you for all your work. > > > > Alexis Wilke > Director > Made to Order Software, Ltd > > e-mail: [EMAIL PROTECTED] > > Web Page: http://www.m2osw.com > Company e-mail: [EMAIL PROTECTED] > Phone: 020 8748 9898 +(44) 20 8748 9898 > Fax:020 8748 4250 +(44) 20 8748 4250 > Address:Britannia House > 1-11 Glenthorne Road > Hammersmith > London W6 0LF > United Kingdom > > > __ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/?.refer=text > __ Do You Yahoo!? Get email at your own domain wit
[BUGS] unix_socket_directory isn't used by all bin tools
Jerome Alet ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description unix_socket_directory isn't used by all bin tools Long Description I use 7.1RC1 I've defined unix_socket_directory to be /var/lib/postgres in /var/lib/data/postgresql.conf it seems that at least createuser doesn't take care of this directory setting, because it searches the socket exclusively in /tmp, so it fails asking whether postmaster is running or not. if I remove the unix_socket_directory setting from postgresql.conf all works fine. System: GNU/LInux Debian Woody Kernel 2.4.2 Glibc 2.2.2 bye, Jerome Alet Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[BUGS] LATIN2 and wrong upper() and lower() functions output
I have PostgreSQL 7.1RC1 with multibyte support and encoding
set to LATIN2.
When I try SELECT UPPER('some_text_with_polish_national_chars');
polish chars are still in lower case but others (abcd...wxyz) are
in upper case.
For example:
(Client encoding is LATIN2)
input:
SELECT UPPER('łąka'); --'ł' and 'ą' are polish national chars
output:
upper
---
łąKA
but it should be:
upper
---
ŁĄKA
Also, ORDER BY works improperly.
for example:
input:
CREATE TABLE test ( name varchar(20) );
INSERT INTO test VALUES('ad');
INSERT INTO test VALUES('aa');
INSERT INTO test VALUES('ac');
INSERT INTO test VALUES('ab');
INSERT INTO test VALUES('ać'); --'ć' is another polish national char
INSERT INTO test VALUES('ae');
SELECT * FROM test ORDER BY name;
output:
name
--
aa
ab
ac
ad
ae
ać
but output should be:
name
--
aa
ab
ac
ać
ad
ae
PS.
I compiled PostgreSQL with --enable-multibyte and
--enable-unicode-conversion.
initdb -E UNICODE -D /usr/local/pgsql/data
createdb pl_test -E LATIN2
Info about my configuration
---
PostgreSQL version:
7.1RC1 compiled by gcc 2.95.2
Platform:
Debian GNU/Linux 2.2 Potato on Intel Celeron 366 MHz with 128 MB RAM
Kernel
2.2.19
C library
2.1
Greetings,
Robert
--
Robert Gaszewski
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [BUGS] pq_shadow
webmaster writes: > [root@crescent1 root]# createuser webmaster -P > Enter password for user "webmaster": > Enter it again: > Shall the new user be allowed to create databases? (y/n) y > Shall the new user be allowed to create more new users? (y/n) y > psql: FATAL 1: SetUserId: user 'root' is not in 'pg_shadow' > createuser: creation of user "webmaster" failed > [root@crescent1 root]# createuser needs to connect to the database in order to create new users. In order to connect to the database, it needs to connect with an *already existing* database user name. "root" is apparently no such user name. If this is a newly initdb'ed site, then the only user name that exists is "postgres" (or whatever the name of your Unix PostgreSQL account). Either you login in (su) as postgres, or you use createuser -U postgres. Incidentally, this is not a bug and should be posted elsewhere. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [BUGS] unix_socket_directory isn't used by all bin tools
> Jerome Alet ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > I've defined unix_socket_directory to be /var/lib/postgres > in /var/lib/data/postgresql.conf > > it seems that at least createuser doesn't take care of this directory > setting, because it searches the socket exclusively in /tmp, so it > fails asking whether postmaster is running or not. The configuration file is only for the server; the clients don't see it. Client tools can use the PGHOST environment variable or the -h option, or whatever else the client has implemented. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] PORTS : Windows 95/98/2000
I have tried with postgresql-7.0-nt-binaries.tar.gz version on Win98(and win 2000). All runs well until I start the postmaster daemon, a this point I obtain this error: $POSTGRES.EXE: *** recreate_mmaps_after_fork_failed Startup failed - abort NOTICE: IpcMemoryDetach: shmdt(0x???): Invalid argument NOTICE: IpcMemoryDetach: shmdt(0x???): Invalid argument NOTICE: IpcMemoryDetach: shmdt(0x???): Invalid argument I'm still waiting for a reply. Bye Sasha. -- Best regards, sasha mailto:[EMAIL PROTECTED] ---(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] unix_socket_directory isn't used by all bin tools
On Fri, 30 Mar 2001, Peter Eisentraut wrote: > > Jerome Alet ([EMAIL PROTECTED]) reports a bug with a severity of 2 > > The lower the number the more severe it is. > > > I've defined unix_socket_directory to be /var/lib/postgres > > in /var/lib/data/postgresql.conf > > > > it seems that at least createuser doesn't take care of this directory > > setting, because it searches the socket exclusively in /tmp, so it > > fails asking whether postmaster is running or not. > > The configuration file is only for the server; the clients don't see it. > Client tools can use the PGHOST environment variable or the -h option, or > whatever else the client has implemented. I disagree partially, correct me if I'm wrong: Unix domain sockets are not available accross the network, so in this particular case (postmaster not listening on tcp) the client and the server are on the same machine, it's mandatory. That's why I think that these programs should take care of the server's configuration if it's available (and no -h or PGHOST option) hoping this clarifies what I meant. bye, Jerome Alet ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] I can't initialize
Fernando Schutz writes: > This error ocurs when I've tried to run /usr/local/pgsql/bin/initdb -D >/usr/local/pgsql/data: > > > > This database system will be initialized with username "postgres". > This user will own all the data files and must also own the server process. > > Fixing permissions on pre-existing data directory /usr/local/pgsql/dados/ > Creating database system directory /usr/local/pgsql/dados//base > Creating database XLOG directory /usr/local/pgsql/dados//pg_xlog > Creating template database in /usr/local/pgsql/dados//base/template1 > ERROR: Error: unknown type 'ame'. Update to 7.1 or search the archives for the fix. (Searching for the error message should provide the answer.) -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] LATIN2 and wrong upper() and lower() functions output
Robert Gaszewski writes:
> When I try SELECT UPPER('some_text_with_polish_national_chars');
> polish chars are still in lower case but others (abcd...wxyz) are
> in upper case.
> I compiled PostgreSQL with --enable-multibyte and
> --enable-unicode-conversion.
Case conversion and ordering are controlled by *locale*, not multibyte.
You need to configure with --enable-locale and set the appropriate LC_*
variables.
http://www.postgresql.org/devel-corner/docs/postgres/charset.html#LOCALE
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(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] RE: [JDBC] Possible large object bug?
Hi, Tom C. and I exchanged a few emails about the issue offlist; Tom spotted after a while that the PostgreSQL data had been clobbered by the output of my cron job (not possible in normal conditions I guess)... end result being he suspects its a hardware glitch or similar (also had 'wc' dump core that same night during the daily periodic run; I'm choosing cosmic radiation ;). I'm going to upgrade to the latest release and also run up another shinier box and see if things work out, I'm sure they will (digging out a tripwire floppy to make ultra sure nothings changed). As a side issue, could/should the vacuumlo functionality be merged with vacuum? Cheers, Joe > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Mount > Sent: Thursday, March 29, 2001 6:52 PM > To: Joe Shevland; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [JDBC] Possible large object bug? > > > At 10:37 27/03/01 +1000, Joe Shevland wrote: > >Hi, > > > >Semi-topical I hope ;) > > Yes semi ;-) > > > I've started using Postgres 7.1 (FreeBSD 4.2-S) and large objects via > > JDBC. (postmaster (PostgreSQL) 7.1beta5) > > I'm forwarding this to the bugs list as it looks like something nasty in > the back end. > > > >Everything has been working nicely with storing/retrieving blobs, until > >last night during a vacuum of the database the backend process crashed > >with the messages added to the end of this email. I'm also using the > >'vacuumlo' contributed code. The order of the cron jobs is: > > > >59 2 * * * postgres /usr/local/pgsql/bin/vacuumlo -v db1 db2 db3 > >59 3 * * * postgres /usr/local/pgsql/bin/vacuumdb -z db1 > >59 4 * * * postgres /usr/local/pgsql/bin/vacuumdb -z db2 > >59 5 * * * postgres /usr/local/pgsql/bin/vacuumdb -z db3 > > > >so I was wondering if there might be a bug in the vacuumlo code (though > >its vacuumdb dying)? Or I was thinking, because they're > development db's, > >that frequent dropping/recreating of tables is maybe causing the > prob? The > >same vacuum commands have run fine before, both from cron and > the command > >line, the only difference was slightly heavier > dropping/recreating yesterday. > > > >I'm yet to see if that particular database is stuffed as I can recreate > >and retest easily enough. Let me know if I can give any further info, > > > >Regards, > >Joe > > > >--- > >NOTICE: Rel pg_attribute: TID 1/115: OID IS INVALID. TUPGONE 1. > >... > >NOTICE: Rel pg_attribute: TID 1/6087: OID IS INVALID. TUPGONE 1. > >NOTICE: Rel pg_attribute: TID 1/6111: OID IS INVALID. TUPGONE 1. > >NOTICE: Rel pg_attribute: TID 1/6112: OID IS INVALID. TUPGONE 1. > >NOTICE: Rel pg_attribute: TID 1/6136: OID IS INVALID. TUPGONE 1. > >NOTICE: Rel pg_attribute: TID 1/6137: OID IS INVALID. TUPGONE 1. > >pqReadData() -- backend closed the channel unexpectedly. > > This probably means the backend terminated abnormally > > before or while processing the request. > >connection to server was lost > >vacuumdb: vacuum db2 failed > >--- > > > >with ~500 of the NOTICE lines then the crash. About 1% give a TUPGONE 0 > >ending instead. > > > > > >---(end of broadcast)--- > >TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[BUGS] Error in the date field (with NULL value...).Thanks!
Subject: Importing data from Informix to PostgreSQL. Error in the date field (WITH NULL value) Hello! I'll try to explain my little problem. Well, I have this table create table mytable ( codice char(16) not null, dt_inizio date, dt_finedate, tipo_operazione char(1), causa_operazione integer ); ok! I find out that pgsql: In my example '' is the NULL value exported from Informix... ! (an ASCII file) INFORMIX PostgreSQL char(16) '' --> blank string (I think it's ok! ) char(1)'' --> blank string (I think it's ok) integer'' --> 0 (is it an error? ) date ''--> ERROR! Bad date external representation '' >> select * from mytable ; codice | dt_inizio | dt_fine | tipo_operazione | causa_operazione ABCEDEF | 2001-03-28 | | |0 XXXYYYAAA23C957Y | 2001-03-28 | | |0 clinica=# insert into mytable values ( '','03/28/2001', '' , '' , '' ); ERROR: Bad date external representation '' ^^^ PostgreSQL doesn't want '' as an input of a date with NULL value: it's necessary to use this kind of insert: >> insert into mytable values ( '','03/28/2001',null,'',''); ^^ Now there is a new line in the table: | 2001-03-28 | | |0 My question: How can I resolv my problem? I have a big data file to import where in the 2nd date field there is '' instead of null How can I "binds" PostgreSQL to consider '' as null ? Many thanks for any suggestions! CIAO! MAURIZIO *** ** Happy surfing on THE NET !! ** ** Ciao by ** ** C R I X 98 ** *** AntiSpam: rimuovere il trattino basso dall'indirizzo per scrivermi... (delete the underscore from the e-mail address to reply) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] BUG: Each UNION | EXCEPT | INTERSECT query must have the same number of columns.
Jacek Konieczny <[EMAIL PROTECTED]> writes: > CREATE TABLE tb1 ( a CHARACTER(10) DEFAULT 'abc', b CHARACTER(10)); > CREATE TABLE tb2 ( a CHARACTER(10), b CHARACTER(10)); > INSERT INTO tb1(b) SELECT b FROM tb2 EXCEPT SELECT b FROM tb1; This is fixed for 7.1. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
