Re: Strange inconsistency with UPDATE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com>
Cc: "Postgres General" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Strange inconsistency with UPDATE
Date: 2007-08-17 03:30:18
Message-ID: 27176.1187321418@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com> writes:
> However, I see some inconsisent behavior from Postgresql. When I issue
> an UPDATE command , it shows me a duplicate violation (which could be
> correct) --

> -# update TABLE set ACOLUMN = lower(ACOLUMN);
> ERROR: duplicate key violates unique constraint "TABLE_ACOLUMN_key"

> So I try to find out the offending values of this ACOLUMN that become
> duplicated when lower(ACOLUMN) is issued:

> -# SELECT lower(ACOLUMN), count(*) FROM TABLE
> GROUP BY lower(ACOLUMN) HAVING count(*) > 1 ;
> -------+-------
> lower | count
> -------+-------
> (0 rows)

Yeah, that *is* pretty bizarre.

We have seen some cases where strcoll() yields inconsistent answers
(leading to arbitrarily silly behavior on Postgres' part) if it is
expecting a character set encoding different from what Postgres is
using. What is your lc_collate setting, and are you sure it matches
the database encoding?

Another possibility is that there's something corrupt about the
TABLE_ACOLUMN_key index ... does reindexing it change the outcome?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-08-17 04:14:29 Re: SELECT ... FOR UPDATE performance costs? alternatives?
Previous Message Michael Glaesemann 2007-08-17 03:27:17 Re: Strange inconsistency with UPDATE