[BUGS] BUG #1932: initdb.log
The following bug has been logged online: Bug reference: 1932 Logged by: zhangsijing Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1-beta2 Operating system: WindowsXP Description:initdb.log Details: When install PostgreSQL/8.1-beta2,I select "Chinese,People's Republic Of China" for Locale, then got these messages in initdb.log: ... creating template1 database in C:/Program Files/PostgreSQL/8.1-beta2/data/base/1 ... FATAL: syntax error in file "C:/Program Files/PostgreSQL/8.1-beta2/data/postgresql.conf" line 386, near token "'s Republic of China'" ... ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1930: Cannot create foreign key constraint
The following bug has been logged online: Bug reference: 1930 Logged by: Warren Little Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: 2.6.10-1.770_FC3smp #1 SMP Thu Feb 24 18:36:43 EST 2005 x86_64 x86_64 x86_64 GNU/Linux Description:Cannot create foreign key constraint Details: pg_restore generates the following error: pg_restore: [archiver (db)] Error from TOC entry 2950; 16386 17827531 FK CONSTRA INT asientry_r0 tigris pg_restore: [archiver (db)] could not execute query: ERROR: insert or update on table "asientry" violates foreign key constraint "asientry_r0" DETAIL: Key (pid)=(AA0003403544) is not present in table "pobject". Command was: ALTER TABLE ONLY asientry ADD CONSTRAINT asientry_r0 FOREIGN KEY (pid) REFERENCES pobject(pid); Also running the alter table after restore generates same constraint violation error. The following query returns one row: select * from asientry, pobject where pobject.pid = 'AA0003403544' and pobject.pid = asientry.pid; Any ideas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1932: initdb.log
"zhangsijing" <[EMAIL PROTECTED]> writes: > creating template1 database in C:/Program > Files/PostgreSQL/8.1-beta2/data/base/1 ... FATAL: syntax error in file > "C:/Program Files/PostgreSQL/8.1-beta2/data/postgresql.conf" line 386, near > token "'s Republic of China'" Known problem, should be fixed in next beta. Thanks for the report! regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1930: Cannot create foreign key constraint
"Warren Little" <[EMAIL PROTECTED]> writes: > pg_restore: [archiver (db)] could not execute query: ERROR: insert or > update on table "asientry" violates foreign key constraint "asientry_r0" > DETAIL: Key (pid)=(AA0003403544) is not present in table "pobject". > Command was: ALTER TABLE ONLY asientry > ADD CONSTRAINT asientry_r0 FOREIGN KEY (pid) REFERENCES pobject(pid); > Also running the alter table after restore generates same constraint > violation error. > The following query returns one row: > select * from asientry, pobject > where pobject.pid = 'AA0003403544' > and pobject.pid = asientry.pid; That seems a bit odd. Are the two pid columns exactly the same datatype (and what is it anyway)? What plan does EXPLAIN show for that SELECT, and what plan do you see for SELECT fk.pid FROM ONLY asientry fk LEFT OUTER JOIN ONLY pobject pk ON pk.pid=fk.pid WHERE pk.pid IS NULL AND fk.pid IS NOT NULL; (which is what is probably being used to test foreign key validity)? regards, tom lane ---(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] BUG #1933: ADD COLUMN with DEFAULT resets table oids
The following bug has been logged online: Bug reference: 1933 Logged by: Duncan Crombie Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: Darwin (OSX) Description:ADD COLUMN with DEFAULT resets table oids Details: The following command causes all oids in the affected table to be reset to new values: ALTER TABLE items ADD COLUMN publish bool DEFAULT true; The following causes no problems: ALTER TABLE items ADD COLUMN publish bool; ALTER TABLE items ALTER publish SET DEFAULT true; ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Error While Connectint to Database
Dear Sir/Madam, My name is N.V.Balaji i am working in Govt. Organisation as Software Engineers, we are using postgresql 8.0 as database, for the Linux operating system the postgres is working well where as for the Windowx XP Operating System while connecting to the database we are getting error as given below. psql: Could not connect to server: Connection refused < 0x0274D/10061> Is the server running on host "" and accepting TCP/IP connections on port 5432? I had checked all the configuration files, the listen_address is set to the local sytem IP address and the tcpip_socket is set to true. Please let me know whether any other settings required to follow while loading in Windows Operating System. -- Have A Nice Day-N.V.Balaji (System Designer)Centre for Good Governance,Road#;25, Jubilee Hills, Hyderabad-500 033.Mobile:9246290438Office:040-235419 07/09 Ext:303
Re: [BUGS] BUG #1815: ECPGdebug causes crash on Windows XP
I remember that I have posted the answer to pgsql.bugs, but now it can only be found here: http://www.talkaboutdatabases.com/group/pgsql.bugs/messages/2346.html Do not know what's wrong with the mail list or my mails. "Bruce Momjian" wrote > > Ah, I have found the cause of the crash, and added documentation about > the cause: > > On Win32, if the ecpg libraries and application are > compiled with different flags, this function call will crash the > application because the internal representation of the FILE > pointers differ. > > While such a mismatch is a problem on all platforms, it is more common > on Win32 where the FILE structure changes for debug, for example. > > -- - > > Michael Meskes wrote: > > On Mon, Aug 15, 2005 at 07:39:42PM +0800, William ZHANG wrote: > > > Yes. It is reproducible. But it works well in MinGW. > > > Is there sth. wrong with the import library lib\ms\libecpg.lib or > > > lib\libecpg.dll? > > > > > > "Joshua Masiko" <[EMAIL PROTECTED]> > > > wrote:[EMAIL PROTECTED] > > > > > > > > ntdll.dll!7c918fea() > > > > ntdll.dll!7c9106eb() > > > > ntdll.dll!7c90104b() > > > > msvcrt.dll!77c3b90d() > > > > msvcrt.dll!77c420e7() > > > > libecpg.dll!6d0c7471() > > > >> ecpgtest.exe!main(int argc=1, char * * > > > > argv=0x003c0d10) Line 5 + 0xc C > > > > ecpgtest.exe!mainCRTStartup() Line 206 + 0x19 C > > > > kernel32.dll!7c816d4f() > > > > kernel32.dll!7c8399f3() > > > > > > > > > > > > The offending line in ecpgtest.pgc is > > > > > > > > ECPGdebug(1,stderr); > > > > > > > > I get the same result even if I use a file handle > > > > obtained by using fopen > > > > Could someone with access to a Windows system have a look at this? I do > > not have one atm. In particular I'd like to know whether it makes a > > difference if your compiled ecpg with threading enabled or not. After > > all without threading the function called does not much, just changing > > two variables and logging the change. > > > > Michael > > -- > > Michael Meskes > > Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) > > ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] > > Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! > > > > ---(end of broadcast)--- > > TIP 2: Don't 'kill -9' the postmaster > > > > -- > 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 6: explain analyze is your friend > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1932: initdb.log
Also reported on http://archives.postgresql.org/pgsql-hackers/2005-09/msg00841.php. ""zhangsijing"" <[EMAIL PROTECTED]> wrote > > The following bug has been logged online: > > Bug reference: 1932 > Logged by: zhangsijing > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1-beta2 > Operating system: WindowsXP > Description:initdb.log > Details: > > When install PostgreSQL/8.1-beta2,I select "Chinese,People's Republic Of > China" for Locale, then got these messages in initdb.log: > > ... > creating template1 database in C:/Program > Files/PostgreSQL/8.1-beta2/data/base/1 ... FATAL: syntax error in file > "C:/Program Files/PostgreSQL/8.1-beta2/data/postgresql.conf" line 386, near > token "'s Republic of China'" > ... > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1908: sql support chinese char error
It looks strange. Can you show us more information: 1. Database encoding: show server_encoding; 2. SQL scripts do create and insert the values. ""wally"" <[EMAIL PROTECTED]> wrote > > The following bug has been logged online: > > Bug reference: 1908 > Logged by: wally > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.3,8.0.2 > Operating system: fc4,fc3,as4 > Description:sql support chinese char error > Details: > > when running the following sql clause,the result shoud be empty, but I get > one incorrect row. > if I use pgsql 7.4 running the same sql clause return correctly. > thanks! > > ulike=# select group_name from group_info where group_name='Ê¿´ó·ò'; > group_name > > ´ó³¤½ñ > (1 row) > > ulike=# select group_name from group_info ; > group_name > - > fFaf > asgfasf > hjlhjl > dfgdj > °³½ÐκÊç·Ò > ´ó³¤½ñ > fdkfjwr > beijing2008 > wws > dhdfj > Ê¿´ó·ò¸Ð > (11 rows) > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1933: ADD COLUMN with DEFAULT resets table oids
"Duncan Crombie" <[EMAIL PROTECTED]> writes: > The following command causes all oids in the affected table to be reset to > new values: > ALTER TABLE items ADD COLUMN publish bool DEFAULT true; Yup, that's an oversight. Fix committed, will appear in 8.0.4. Thanks for the report! regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
