Please Cc: to teo@flex.ro
Hello all,
I think I have found a bug in unique index.
The bug has been tested with:
-PostgreSQL 6.5 final version running on a RedHat 5.2 i386
-PostgreSQL 6.5 final version running on a RedHat 6.0 i386
-PostgreSQL 6.4.2 running on a RedHat 5.2 i386
and the results are the same.
Create a test database and create the following table:
CREATE TABLE "livrari" ( "nr_npr" int4, "data_npr" date, "nr_ordin" int4, "sursa" character varying(32), "destinatie"
charactervarying(32), "produs" character varying(8), "spatii_sursa" text, "caracteristici" text, "calitate" character
varying(16),"nr_transport" character varying(16), "delegat" character varying(32), "brut" float8, "tara" float8, "net"
float8,"cod_operatiune" int4, "pret" float8, "tva" float8, "qwerty12345ytrewq54321" int4);
Then try creating the following unique index :
test=> create unique index livrari_unic on livrari (nr_npr, data_npr,
nr_ordin, sursa, destinatie, produs, spatii_sursa, caracteristici,
calitate, nr_transport, delegat);
CREATE
Now try to select the records from table (actually no records, nothing
has been inserted):
test=> select * from livrari;
ERROR: index_info: no amop 403 655369 1
I thought that my database is somehow corrupted and tried to vacuum it :
test=> vacuum analyze;
VACUUM
Now, I was trying to select again the records:
test=> select * from livrari;
pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is
impossible. Terminating.
Are the some limitations on the number and type of the fields contained
by the index?
Is there some mistakes that I make?
Please Cc: to teo@flex.ro
Best regards,
--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA
