From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Phill Kenoyer <pgsql(at)c0de(dot)net> |
Cc: | Ian Barwick <barwick(at)gmx(dot)net>, <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Primary Key Problems |
Date: | 2001-12-10 21:47:23 |
Message-ID: | 20011210134414.P70079-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Fri, 7 Dec 2001, Phill Kenoyer wrote:
> I took your advice and checked the string size using char_length() and
> octet_length(). They are the same.
>
> octet_length | stock | octet_length | inventory_type | client_id
> 5 | 10725 | 4 | used | 60
> 5 | 10725 | 4 | used | 60
>
> I do a daily pg_dump of the database and the scheme I posted was from
> that. So the primary key is still active.
>
> I just dont understand how I can have dups in the primary keys, unless
> it is a bug.
Hmm, what does explain show for your query? I'd wonder if the unique
index got corrupted for some reason and so didn't see the first value
when the second was inserted. If you search for a specific value
and try to force an index scan (use set enable_seqscan=false) do you
still get two rows (and does explain in that case show it using the
index?)
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2001-12-10 21:54:00 | Re: table name as parameter in pl/psql |
Previous Message | ph wuidart | 2001-12-10 20:06:11 | Postgresql on win2000 |