Re: BUG #3724: Duplicate values added to table despite unique index

From: "Mason Hale" <masonhale(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3724: Duplicate values added to table despite unique index
Date: 2007-11-07 21:08:58
Message-ID: 8bca3aa10711071308y4e3ffc4er8ac18f45deb77bf9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> >> 2. Can you check that there are still 1 (rather than 0) copies of the
> >> rows in the 8.2.5 DB?
>
> > Yes, we have 1 of each row (I kept the most recently updated version of
> > each):
>
> Ah, I forgot that the rows were obviously not identical because of the
> differing updated_at values.
>
> Tell us more about the updating process --- is it likely that there
> could be conflicting concurrent updates on a row? What does your
> app do in such cases?
>

We do some application-layer locking to prevent the same 'topic-version'
from being updated at the same time.
But there could be a bug somewhere that let's that happen, in which case,
concurrent updates of the same row could occur. So I guess I would say it is
unlikely, but possible.

If there is a concurrent update of the same row, I guess we're relying on
Postgres to handle that. If that results in a deadlock or any other error,
then we catch and log the error, mark the update job as failed (in another
db table) and try again. In most every case, the same request will complete
successfully on a second try. In this case, every update to the rows in
question was resulting in a unique index violation, which resulted in a
near-constant stream of errors being logged.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Pedro Gimeno 2007-11-07 22:04:53 Re: Test suite fails on alpha architecture
Previous Message heasley 2007-11-07 20:20:50 BUG #3728: pthread autoconf hangs