Re: [BUGS] Postgres Python API problem
Ruby, to my heat-challenged ears and eyes this message looks as if the python server side scripting "python" is built for python 2.3; and your installed python is 2.4 So... I recommend installing python 2.3 and try again. Harald2005/6/23, Ruby Murillo <[EMAIL PROTECTED]>: Hi, We keep getting this message: import pgdb /usr/local/lib/python2.4/site-packsges/pgdb.py:56: RuntimeWarning: Python C API version mismatch for module _pg: This Python has API version 1012, module _pg has version 1011 import pg /usr/local/lib/python2.4/site-packsges/pgdb.py:8: RuntimeWarning: Python C API version mismatch for module _pg: This Python has API version 1012, module _pg has version 1011 I have installed Postgres 3 years from RPM and just included python(2.2) in the installation. This time I need to use python but then I keep getting this Warning/error message. Please let me know if this is a bug or is this just a warning. I currently have postgres and being access by my perl appl and don't want to mess with it. So if you could guide me on how I could make my python up-to-date to the API, that would be great. Thanks, Ruby -- GHUM Harald Massapersuasion python postgresqlHarald Armin MassaReinsburgstraße 202b70197 Stuttgart0173/9409607
[BUGS] BUG #1728: unable to connect from other stations
The following bug has been logged online: Bug reference: 1728 Logged by: Christian Mercure Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows XP Description:unable to connect from other stations Details: I am evaluating backend server to use with Microsoft Access. I have installed MySQL and was easily able to connect to the server from network stations using ODBC data source. I am now evaluating PostGreSQL and cannot connect to it form other stations on the network. On the server I can create an ODBC file using localhost as the server name. It works and my Access frontend can connect to the server tables. When trying to connect from another station it does not work. I have tried to replace the server name localhost with the name of my server (example: DBSERVER), I have disable Windows XP firewall, I have put the following line in pg_hba.conf hostall all 192.168.1.1/192.168.1.255 md5 and the following line in postgresql.conf listen_addresses = '*' Nothing works. What is required to connect from other stations. If I cannot resolved this issues I will go with MySQL. Thanks ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1728: unable to connect from other stations
On Fri, 24 Jun 2005, Christian Mercure wrote: > > The following bug has been logged online: > > Bug reference: 1728 > Logged by: Christian Mercure > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0 > Operating system: Windows XP > Description:unable to connect from other stations > Details: > > I am evaluating backend server to use with Microsoft Access. > I have installed MySQL and was easily able to connect to the server from > network stations using ODBC data source. > > I am now evaluating PostGreSQL and cannot connect to it form other stations > on the network. > On the server I can create an ODBC file using localhost as the server name. > It works and my Access frontend can connect to the server tables. > > When trying to connect from another station it does not work. I have tried > to replace the server name localhost with the name of my server (example: > DBSERVER), I have disable Windows XP firewall, I have put the following line > in pg_hba.conf > > host all all 192.168.1.1/192.168.1.255 md5 I think you'd want something like 192.168.1.0/24 or 192.168.1.1 255.255.255.0 there. When I try something like the above I get LOG: invalid entry in file "/usr/local/pgsql-8.0/data/pg_hba.conf" at line 74, token "192.168.0.1/192.168.0.255" FATAL: missing or erroneous pg_hba.conf file ---(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 #1730: insert into x1.tbl select x2.tbl dont work
The following bug has been logged online: Bug reference: 1730 Logged by: Krasimir dimitrov Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Debian Linux Description:insert into x1.tbl select x2.tbl dont work Details: Hello there, I use postgresql-7.4(7.4.8-9) on debian with kernel 2.6.11.2 My idea is: when delete from table cms.news trigger insert data in archive.news I found a bug in Postgres-7.4. before running: delete from cms.news where uid_news='118dd5bd-19be-416f-bf68-f9682147184c'; data in table cms.code_company is: aiidatapro.net=# select * from cms.code_company; id_company_coded |uid_news_coded| fk_id_base_company_coded --+--+-- 2 | 118dd5bd-19be-416f-bf68-f9682147184c | 2 3 | 118dd5bd-19be-416f-bf68-f9682147184c | 3 (2 rows) Bug is appear when run insert into archive.code_company select * from cms.code_company WHERE uid_news_coded=uid; in my trigger "on delete" in table cms.news result is: aiidatapro.net=# select * from cms.code_company; id_company_coded |uid_news_coded| fk_id_base_company_coded --+--+-- 2 | 118dd5bd-19be-416f-bf68-f9682147184c | 2 3 | 118dd5bd-19be-416f-bf68-f9682147184c | 3 2 | 118dd5bd-19be-416f-bf68-f9682147184c | 2 3 | 118dd5bd-19be-416f-bf68-f9682147184c | 3 but I set unique constraint : ALTER TABLE cms.code_company ADD CONSTRAINT code_company_uid_news_coded_key UNIQUE(uid_news_coded, fk_id_base_company_coded); This couldn't be happend ! constraint works when insert: aiidatapro.net=# insert into cms.code_company (id_company_coded,uid_news_coded,fk_id_base_company_coded) values (2,'118dd5bd-19be-416f-bf68-f9682147184c',2); ERROR: duplicate key violates unique constraint "code_company_pkey" please check query : insert into x1.tbl select from x2.tbl tanks p.s. I send copy of this mail to pgsql-bugs@postgresql.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] BUG #1731: Indexes are corrupt following an unclean shutdown
The following bug has been logged online: Bug reference: 1731 Logged by: Adam Kruger Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.03 Operating system: Linux Description:Indexes are corrupt following an unclean shutdown Details: I have encountered a condition similar to those referenced at: http://archives.postgresql.org/pgsql-admin/2005-06/msg00051.php and http://archives.postgresql.org/pgsql-bugs/2005-06/msg00142.php I have come up with a simple method for reproducing this error condition. This method is reproducable on a linux (2.6) system with ext3 file systems and hard disk write caching disabled. 1. Run the following script: # #!/bin/sh /bin/su - postgres -c '/usr/bin/createdb test' && \ echo "create table t1 ( name varchar(20) primary key, address varchar(20) );" \ | (/bin/su - postgres -c '/usr/bin/psql test ') && \ echo "create table t2 ( name varchar(20) primary key, address varchar(20) );" \ | (/bin/su - postgres -c '/usr/bin/psql test ') && \ echo "create table t3 ( name varchar(20) primary key, address varchar(20) );" \ | (/bin/su - postgres -c '/usr/bin/psql test ') && \ echo "create table t4 ( name varchar(20) primary key, address varchar(20) );" \ | (/bin/su - postgres -c '/usr/bin/psql test ') && \ echo "create table t5 ( name varchar(20) primary key, address varchar(20) );" \ | (/bin/su - postgres -c '/usr/bin/psql test ') && \ echo "create table t6 ( name varchar(20) primary key, address varchar(20) );" \ | (/bin/su - postgres -c '/usr/bin/psql test ') && \ echo "create table t7 ( name varchar(20) primary key, address varchar(20) );" \ | (/bin/su - postgres -c '/usr/bin/psql test ') && \ echo "create table t8 ( name varchar(20) primary key, address varchar(20) );" \ | (/bin/su - postgres -c '/usr/bin/psql test ') && \ echo "create table t9 ( name varchar(20) primary key, address varchar(20) );" \ | (/bin/su - postgres -c '/usr/bin/psql test ') # 2. When the script completes, press the reset button. 3. When the system comes back up, log on and try the following: vacuumdb -Upostgres test An error is returned indicating that an index is not a valid btree. ---(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 #1730: insert into x1.tbl select x2.tbl dont work
On Fri, Jun 24, 2005 at 04:08:58PM +0100, Krasimir dimitrov wrote: > > aiidatapro.net=# select * from cms.code_company; > id_company_coded |uid_news_coded| > fk_id_base_company_coded > --+--+-- > 2 | 118dd5bd-19be-416f-bf68-f9682147184c | > 2 > 3 | 118dd5bd-19be-416f-bf68-f9682147184c | > 3 > (2 rows) > > Bug is appear when run > > insert into archive.code_company select * from cms.code_company WHERE > uid_news_coded=uid; The above statement inserts into archive.code_company... > in my trigger "on delete" in table cms.news > result is: > > aiidatapro.net=# select * from cms.code_company; ...and the above query selects from cms.code_company. Why are you looking at cms.code_company when you inserted into archive.code_company? Are you using inheritance? The following query results seem to imply that. > id_company_coded |uid_news_coded| > fk_id_base_company_coded > --+--+-- > 2 | 118dd5bd-19be-416f-bf68-f9682147184c | > 2 > 3 | 118dd5bd-19be-416f-bf68-f9682147184c | > 3 > 2 | 118dd5bd-19be-416f-bf68-f9682147184c | > 2 > 3 | 118dd5bd-19be-416f-bf68-f9682147184c | > 3 > > but I set unique constraint : > > ALTER TABLE cms.code_company ADD CONSTRAINT > code_company_uid_news_coded_key UNIQUE(uid_news_coded, > fk_id_base_company_coded); > > This couldn't be happend ! Does archive.code_company inherit cms.code_company? That would explain why inserting into archive.code_company causes records to appear in cms.code_company, and it would explain why those records don't cause a unique constraint violation, since constraint support in inherited tables is documented as being deficient. See the last paragraph of the following page: http://www.postgresql.org/docs/7.4/static/ddl-inherit.html The 8.0 documentation is a bit more descriptive: http://www.postgresql.org/docs/8.0/static/ddl-inherit.html If you don't think inheritance is the problem, then please post a complete example. That is, all SQL statements that somebody could load into an empty database to duplicate the problem. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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] Timestamp in log for prepared queries
This problem shows up in the pglog for systems running
slony, but is not unique to slony necessarily.
The timestamp on queries logged to pglog corresponds
to the time the query was prepared rather than when
the query was run SPI_exec.
With slony, the same prepared statements may be used
for days or weeks or ???
This causes the pglog file to have interleaved within
it slony activity dated days previously along with
current update activity.
I discussed this briefly with Jan who agreed it was
a bug in the pg logging rather than a slony anomally.
In this spot of pglog, you see slony pre-prepared
queries timestamped 06-10 16:18:47 (et al) interleaved with a
connection error timestamped 06-16 16:00.
dev_core-2005-06-10 16:18:47 PDT-LOG: duration: 21.882 ms statement: select
con_origin, con_received, max(con_seqno) as con_seqno,
max(con_timestamp) as con_timestamp from "_plaa03_staging".sl_confirm where
con_received <> 2 group by con_origin, con_received
dev_core-2005-06-10 15:01:20 PDT-LOG: duration: 96.519 ms statement: notify
"_plaa03_staging_Event"; notify "_plaa03_staging_Confirm"; insert into
"_plaa03_staging".sl_event (ev_origin, ev_seqno, ev_timestamp, ev_minxid,
ev_maxxid, ev_xip, ev_type ) values ('2', '51740', '2005-06-16
16:00:40.947355', '3246520', '3627300',
'''3603570'',''3603741'',''3620474'',''3509792'',''3246520'',''3599413'',''3613734''',
'SYNC'); insert into "_plaa03_staging".sl_confirm (con_origin, con_received,
con_seqno, con_timestamp)values (2, 1, '51740', CURRENT_TIMESTAMP); commit
transaction;
dev_core-2005-06-10 16:18:47 PDT-LOG: duration: 21.911 ms statement: select
con_origin, con_received, max(con_seqno) as con_seqno,
max(con_timestamp) as con_timestamp from "_plaa03_staging".sl_confirm where
con_received <> 2 group by con_origin, con_received [unknown]-2005-06-16
16:00:48 PDT-LOG: connection received: host=[local] port=
dev_coree-2005-06-16 16:00:48 PDT-LOG: connection authorized: user=postgres
database=dev_coree dev_coree-2005-06-16 16:00:48 PDT-FATAL: database
"dev_coree" does not exist
dev_core-2005-06-10 15:01:20 PDT-LOG: duration: 3.766 ms statement: select
"_plaa03_staging".createEvent('_plaa03_staging', 'SYNC', NULL);
dev_core-2005-06-10 15:01:20 PDT-LOG: duration: 81.188 ms statement: commit
transaction;
dev_core-2005-06-10 15:25:15 PDT-LOG: duration: 22.012 ms statement: fetch
100 from LOG;
dev_core-2005-06-10 15:01:20 PDT-LOG: duration: 183.405 ms statement: select
"_plaa03_staging".forwardConfirm(1, 2, '53126', '2005-06-16 16:00:48.620222');
dev_core-2005-06-10 16:18:47 PDT-LOG: duration: 22.126 ms statement: select
con_origin, con_received, max(con_seqno) as con_seqno,
max(con_timestamp) as con_timestamp from "_plaa03_staging".sl_confirm where
con_received <> 2 group by con_origin, con_received
elein
[EMAIL PROTECTED]
---(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
