I have a table that looks like this:

Table "public.hd"
Column | Type
| Modifiers
-------------------+-----------------------------+-------------------------------------------------------------------------
d_id | integer | not null default
nextval('public.hd_d_id_seq'::text)
h_id | integer | not null
src | text |
p_q | integer | not null default 1
c_id | integer | not null
insert_time | timestamp without time zone | default now()
Indexes:
"hd_pkey" PRIMARY KEY, btree (d_id)
"hd_idx" btree (h_id, c_id)


_Log output:_

[2005-03-24 15:33:25 EST - 13882 - dbname - 4052774] LOG: statement:
INSERT INTO hd (c_id, h_id, p_q) VALUES ((SELECT c_id FROM c WHERE e_id
= 'tester1'), (SELECT h_id FROM h JOIN c USING (c_id) WHERE e_id =
'tester1' AND h.active AND NOT p_c),10);

[2005-03-24 15:33:25 EST - 13882 - dbname - 4052774] ERROR: duplicate
key violates unique constraint "hd_pkey"


These inserts are being executed ever 1.5 seconds on this database.
This error does not happen often and appears to happen randomly. No
other inserts are being executed on this table except this one. From
our current tests 99% of the inserts go through, with the exception of
these few. Honestly, I don't see how this could be caused from
something on my end. The primary key value is being determined by a
default, so everything should be handled within the database. I'm using
postgres 8.0.1. Any ideas?

Thanks for the assist!

Kris

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On Thu, 2005-03-24 at 15:21, Kris Kiger wrote:
> I have a table that looks like this:
>
> Table "public.hd"
> Column | Type
> | Modifiers
> -------------------+-----------------------------+-------------------------------------------------------------------------
> d_id | integer | not null default
> nextval('public.hd_d_id_seq'::text)
> h_id | integer | not null
> src | text |
> p_q | integer | not null default 1
> c_id | integer | not null
> insert_time | timestamp without time zone | default now()
> Indexes:
> "hd_pkey" PRIMARY KEY, btree (d_id)
> "hd_idx" btree (h_id, c_id)
>
>
> _Log output:_
>
> [2005-03-24 15:33:25 EST - 13882 - dbname - 4052774] LOG: statement:
> INSERT INTO hd (c_id, h_id, p_q) VALUES ((SELECT c_id FROM c WHERE e_id
> = 'tester1'), (SELECT h_id FROM h JOIN c USING (c_id) WHERE e_id =
> 'tester1' AND h.active AND NOT p_c),10);
>
> [2005-03-24 15:33:25 EST - 13882 - dbname - 4052774] ERROR: duplicate
> key violates unique constraint "hd_pkey"
>
>
> These inserts are being executed ever 1.5 seconds on this database.
> This error does not happen often and appears to happen randomly. No
> other inserts are being executed on this table except this one. From
> our current tests 99% of the inserts go through, with the exception of
> these few. Honestly, I don't see how this could be caused from
> something on my end. The primary key value is being determined by a
> default, so everything should be handled within the database. I'm using
> postgres 8.0.1. Any ideas?


Are you sure someone hasn't been messing with your sequence some how?
That's the only way I've seen these kinds of things happen before.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

I'm positive no one else has been in the database. There are two of us
who work on it and we have been side by side all afternoon. The problem
appears to be purely internal to the database. I'm running more tests
as we speak and we are still recieving the same sporadic errors. It
works for a long amount of time and then the error occurs, but then
things work fine again for a while. The inconsistency is quite troubling.

Thanks

Kris


Scott Marlowe wrote:

>Are you sure someone hasn't been messing with your sequence some how?
>That's the only way I've seen these kinds of things happen before.
>
>


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On Thu, Mar 24, 2005 at 04:45:02PM -0500, Kris Kiger wrote:

> I'm positive no one else has been in the database. There are two of us
> who work on it and we have been side by side all afternoon. The problem
> appears to be purely internal to the database. I'm running more tests
> as we speak and we are still recieving the same sporadic errors. It
> works for a long amount of time and then the error occurs, but then
> things work fine again for a while. The inconsistency is quite troubling.

What are the results of the following queries?

SELECT max(d_id) FROM hd;
SELECT * FROM hd_d_id_seq;

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Kris Kiger <kris@musicrebellion.com> writes:
> I'm positive no one else has been in the database. There are two of us
> who work on it and we have been side by side all afternoon. The problem
> appears to be purely internal to the database. I'm running more tests
> as we speak and we are still recieving the same sporadic errors.

Well, it would be good to positively refute Scott's theory. Let's see
select max(d_id) from hd;
and
select * from hd_d_id_seq;

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On Thursday 24 March 2005 1:45 pm, Kris Kiger wrote:
> I'm positive no one else has been in the database. There are two
> of us who work on it and we have been side by side all afternoon.
> The problem appears to be purely internal to the database. I'm
> running more tests as we speak and we are still recieving the same
> sporadic errors. It works for a long amount of time and then the
> error occurs, but then things work fine again for a while. The
> inconsistency is quite troubling.

Try turning up logging to catch as much as possible (all statements,
connections and everything). Don't know if it will yield a clue but
it's a place to start. At least it might trap any statement, however
generated, that is messing with the sequence if that turns out to be
the culprit or alternately it might eliminate that possibility.

Cheers,
Steve


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Heh, I see. The sequence currval was set lower than what was already in
the table. It just so happened we had holes in our data for the values
it was selecting. Thanks for pointing that out!

Kris

Michael Fuhr wrote:

>On Thu, Mar 24, 2005 at 04:45:02PM -0500, Kris Kiger wrote:
>
>
>
>>I'm positive no one else has been in the database. There are two of us
>>who work on it and we have been side by side all afternoon. The problem
>>appears to be purely internal to the database. I'm running more tests
>>as we speak and we are still recieving the same sporadic errors. It
>>works for a long amount of time and then the error occurs, but then
>>things work fine again for a while. The inconsistency is quite troubling.
>>
>>
>
>What are the results of the following queries?
>
>SELECT max(d_id) FROM hd;
>SELECT * FROM hd_d_id_seq;
>
>
>


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly