Thread: BUG #7805: Inconsistency, multiple versions

BUG #7805: Inconsistency, multiple versions

From
gerydeft@gmail.com
Date:
The following bug has been logged on the website:

Bug reference:      7805
Logged by:          Gery Deft
Email address:      gerydeft@gmail.com
PostgreSQL version: 9.2.2
Operating system:   Windows Server, Windows 7,Ubuntu linux
Description:        =


Hi,

Versions: 9.2.*,8.4.*
Our project uses PostgreSQL as main database system, but recently we found
that PG have serious inconsistency problems.
We have about 60 connections to the database, reading and writing it most of
the time.
It does not matter if we use inline SQL, stored procedures or
pg_advisory_lock, after a few hundreds of thousand records the database will
contain duplication in a key field.
Example:
CREATE TABLE <table>
(
  id serial NOT NULL,
  name character varying(100),
  ...
CONSTRAINT domain_pkey PRIMARY KEY (id),
  CONSTRAINT domain_name_key UNIQUE (name)
---------------------------------
SELECT id, name,length(name) FROM <table> where name like 'samedata%';
3161132;"samedata";8
7821530;"samedata";8
1962653;"samedata";8

I made ASCII comparison and they are identical.

This bug corrupts the workflow of our project, please fix it as soon as
possible.

Thanks,
Gery
 =

Re: BUG #7805: Inconsistency, multiple versions

From
Heikki Linnakangas
Date:
On 14.01.2013 11:37, gerydeft@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference:      7805
> Logged by:          Gery Deft
> Email address:      gerydeft@gmail.com
> PostgreSQL version: 9.2.2
> Operating system:   Windows Server, Windows 7,Ubuntu linux
> Description:
>
> Hi,
>
> Versions: 9.2.*,8.4.*
> Our project uses PostgreSQL as main database system, but recently we found
> that PG have serious inconsistency problems.
> We have about 60 connections to the database, reading and writing it most of
> the time.
> It does not matter if we use inline SQL, stored procedures or
> pg_advisory_lock, after a few hundreds of thousand records the database will
> contain duplication in a key field.
> Example:
> CREATE TABLE<table>
> (
>    id serial NOT NULL,
>    name character varying(100),
>    ...
> CONSTRAINT domain_pkey PRIMARY KEY (id),
>    CONSTRAINT domain_name_key UNIQUE (name)
> ---------------------------------
> SELECT id, name,length(name) FROM<table>  where name like 'samedata%';
> 3161132;"samedata";8
> 7821530;"samedata";8
> 1962653;"samedata";8
>
> I made ASCII comparison and they are identical.

It's hard to believe that there would be any fundamental bug like that
in constraint checking, or we would've gotten plenty of reports of it
before. There must be something peculiar about your environment, but
without more details, it's impossible to guess what it might be. If you
can put together a smaller test case to reproduce the issue and post
that, that would make it possible for someone to diagnose the problem.
If that's not feasible, please explain in more detail what does the
table definition look like exactly, and how you're loading the data.

- Heikki