[BUGS] Bonjour registration on Intel Macs is broken
The call to DNSServiceRegistrationCreate in postmaster.c does incorrect byte-swapping on the port number which causes the Bonjour registration call to fail on Intel Macs.This patch uses htons() instead of htonl() and fixes this bug. Bonjour for Intel Mac.patch Description: Binary data Ashley Clark smime.p7s Description: S/MIME cryptographic signature
Re: [BUGS] [PATCHES] Bonjour registration on Intel Macs is broken
On Sat, 2006-03-18 at 15:35 -0600, Ashley Clark wrote: > The call to DNSServiceRegistrationCreate in postmaster.c does > incorrect byte-swapping on the port number which causes the Bonjour > registration call to fail on Intel Macs. Thanks for the patch -- applied to HEAD and back branches, back to 7.4. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2334: WHERE IN (SUBSELECT) fails when column is null
The following bug has been logged online: Bug reference: 2334 Logged by: Patrick Narkinsky Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Mac OS X Description:WHERE IN (SUBSELECT) fails when column is null Details: This may be expected behavior, but it certainly doesn't seem right to me, and it works as expected in sqlite. The database is as follows: BEGIN TRANSACTION; create table a ( id integer, text varchar(20) ); INSERT INTO a VALUES(0,'test'); INSERT INTO a VALUES(1,'test2'); create table b ( id integer, a_id integer); INSERT INTO b VALUES(0,NULL); INSERT INTO b VALUES(1,NULL); INSERT INTO b VALUES(2,NULL); COMMIT; The following query returns everything in a in sqlite, but returns nothing in postgresql: select * from a where a.id not in (select a_id from b); On postgresql, it works as expected when a_id has a non-null value. I'm not expert enough on SQL to say which is wrong, but it appears to me that the SQLite behavior makes a lot more sense. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2335: Order of data in data-only dumps
The following bug has been logged online: Bug reference: 2335 Logged by: Jozef Behran Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.0 Operating system: Linux (Mandriva Linux 10.0) Description:Order of data in data-only dumps Details: When doing a data-only dump, the tables are dumped in alphabetical order. This is unfortunate as I might want to fetch the file into a fully created schema (including indices/constraints) for example to prevent bad data from being fetched without an error ot to accomodate old data in a new schema and the alphabetical order of the tables may be wrong. Older versions (7.x particularly) ensure the order of the tables in the dump is such that it can be fetched into fully created schema without problems. It is OK to have the tables ordered aplabetically in full dumps as it is unlikely to fetch such dump into something other than an empty database. To see some problematic data try: BEGIN; CREATE TABLE b ( id int4, PRIMARY KEY(id) ); CREATE TABLE a ( id int4, other int4 references b on update cascade on delete cascade ); INSERT INTO b VALUES (1); INSERT INTO a VALUES (1,1); COMMIT; Then try pg_dump -a The pg_dump will dump a, then b but it should do it in reverse order. I think the few more CPU cycles needed to sort the tables like in 7.x series is not worth the reduced usability of the dumps when incorrect table order is used. Especially when the order of data does not break anything even in the full dump. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2332: commands ignored until end of transaction block
There must be some error caused by the SQL statements sent by the application or driver. You can log the SQL statements by setting log_statement to true in postgres.conf. Regards, William ZHANG ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2333: dropdb ignores the database name argument
The following bug has been logged online: Bug reference: 2333 Logged by: kevin barnes Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: ubuntu 5.10 Description:dropdb ignores the database name argument Details: In the 8.1 release on Unbuntu 5.10 there is an error with the dropdb command in /usr/bin. The error manifests itself by not respecting the DBNAME argument. It assumes that you want to connect to a database named 'postgres' and ignores whatever argument you give it. The error returned is: dropdb: database removal failed: ERROR: database "postgres" does not exist The error is actually correct, because I do not have a database named postgres, but the command does not work correctly. I downgraded through apt-get to 8.0 and dropdb works as expected. I believe the version I was running was 8.1.3. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2334: WHERE IN (SUBSELECT) fails when column is null
On Fri, 17 Mar 2006, Patrick Narkinsky wrote: > This may be expected behavior, but it certainly doesn't seem right to me, > and it works as expected in sqlite. > > The database is as follows: > > BEGIN TRANSACTION; > create table a ( > id integer, > text varchar(20) > ); > INSERT INTO a VALUES(0,'test'); > INSERT INTO a VALUES(1,'test2'); > create table b ( > id integer, > a_id integer); > INSERT INTO b VALUES(0,NULL); > INSERT INTO b VALUES(1,NULL); > INSERT INTO b VALUES(2,NULL); > COMMIT; > > The following query returns everything in a in sqlite, but returns nothing > in postgresql: > > select * from a where a.id not in (select a_id from b); AFAICS, our behavior follows SQL. a NOT IN b is NOT(a IN b) IN is defined in terms of = ANY. a =ANY (b) is basically (by my reading of 8.8 anyway): True if a = bi for some bi in b False if b is empty or a <> bi for all bi in b Unknown otherwise Since a <> NULL returns unknown, the second one won't come up, so the whole expression won't ever be true after the negation. It might be false or it might be unknown. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2333: dropdb ignores the database name argument
kevin barnes wrote: > > The following bug has been logged online: > > Bug reference: 2333 > Logged by: kevin barnes > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1 > Operating system: ubuntu 5.10 > Description:dropdb ignores the database name argument > Details: > > In the 8.1 release on Unbuntu 5.10 there is an error with the dropdb command > in /usr/bin. The error manifests itself by not respecting the DBNAME > argument. It assumes that you want to connect to a database named 'postgres' > and ignores whatever argument you give it. The error returned is: > > dropdb: database removal failed: ERROR: database "postgres" does not exist > > The error is actually correct, because I do not have a database named > postgres, but the command does not work correctly. > > I downgraded through apt-get to 8.0 and dropdb works as expected. I believe > the version I was running was 8.1.3. I think something strange is happening in your installation. I can not reproduce your failure. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2333: dropdb ignores the database name argument
kevin barnes wrote: > In the 8.1 release on Unbuntu 5.10 there is an error with the dropdb command > in /usr/bin. The error manifests itself by not respecting the DBNAME > argument. It assumes that you want to connect to a database named 'postgres' > and ignores whatever argument you give it. The error returned is: > > dropdb: database removal failed: ERROR: database "postgres" does not exist > > The error is actually correct, because I do not have a database named > postgres, but the command does not work correctly. I think what is happening here is that dropdb is trying to connect to the postgres database to issue the DROP DATABASE command, and fails because it doesn't exist. I thought it was fixed not long ago to retry by connecting to template1 if postgres didn't exist; maybe it wasn't really done and I'm misremembering, or maybe you're using a version without the fix (and thus you should upgrade). The obvious workaround is to create a database named postgres. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
