Re: database not enforcing unqiue constriant - Mailing list pgsql-general

From Merlin Moncure
Subject Re: database not enforcing unqiue constriant
Date
Msg-id b42b73150610270638p5cde5f6fm98a4b9aaf579bcbb@mail.gmail.com
Whole thread Raw
In response to Re: database not enforcing unqiue constriant  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
On 10/27/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> > Do they vacuum enough? I have seen problems with PostgreSQL (albeit not
> > since 7.3) where a unique constraint would not enforce because of index
> > bloat.
>
> Huh??  This would qualify as a serious bug.  Failure to vacuum should
> bring performance loss, but not functionality loss (modulo the Xid
> wraparound issue).

right, i think he was talking about the wraparound issue. definately
does not apply here.

> I do remember vaguely the failure Merlin alludes to, and IIRC it has
> been reported a couple of times by other people but has never been
> resolved because it was awfully difficult to reproduce.  Maybe it has
> something to do with the btree bug that Tom diagnosed on Wednesday?  The
> uniqueness-checking code is ... weird.

I'm hoping this is the case.  When 8.2 comes out I'm going to upgrade
their servers to that version and hope for the best.

> I guess if it was the same bug, you could not vacuum the table, which I
> assume you do regularly.

right.  Since these are gererally not 24 hour operations, vacuum is
performed regularly on a schedule.  Also, I am going to implement a
sweep which checks each table for duplicates on each constraint.

Since this is a converted ISAM system, the query volume is enormous
but the data turnover is not.  Pessimistic locks are enforced with the
userlock module.  Statements executed over ExecPrepared 100% of the
time.

merlin

pgsql-general by date:

Previous
From: Richard Broersma Jr
Date:
Subject: Re: pg_dumpall failing from possible corrupted shared memory
Next
From: Alvaro Herrera
Date:
Subject: Re: Send email from PostgreSQL, may I ?