> >> 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.