Re: [GENERAL] Another unexpected behaviour

Thanks. But I am not looking for how to avoid the problem at this moment, I am more interested in why PostgreSQL is designed to work this way. To make the problem more obvious, drop table if exists t1; create table t1 (f1 int); create unique index uix_t1 on t1(f1) ; insert into t1(f1) values (1),

Re: [GENERAL] Another unexpected behaviour

Thanks for the reply. You are right, the result is all or nothing, so it's still atomic. I found my mistake and posted a clarification for my question. I know in PostgreSQL 9.0 unique constraint can be set to deferrable. However still no luck for unique indexes. The real question is that why Pos

[GENERAL] interesting finding on order by behaviour

I ran the same tests in SQL Server 2008R2, Oracle10 and PostgreSQL 9.0.4 and found something interesting... set up = drop table t1 create table t1 (f1 varchar(100)) insert into t1 (f1) values ('AbC') insert into t1 (f1) values ('CdE') insert into t1 (f1) values ('abc') insert into t1 (f1) valu

[GENERAL] Can someone help explain what's going on from the attached logs?

The log is getting from PostgreSQL 9.0.4 Basically we set up streaming replication hot-standby slave while master is under heavy load The slave started but not accepting read-only queries, every request will trigger the "FATAL: the database system is starting up" error. The slave will eventually