> >> 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.
>
"Mason Hale" <[EMAIL PROTECTED]> writes:
> On Nov 6, 2007 1:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Mph. I'm afraid the evidence is mostly gone then, and we probably won't
>> be able to figure out what happened.
> Sorry about that. But I had to get things back up and running.
Understood, b
On Nov 6, 2007 1:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> For that matter, do you still see dups if you prevent use of the index
> >> in the 8.2.5 query? Maybe it's that index that is corrupt.
>
> > Unfortunately, I'm not able to test that at this
"Mason Hale" <[EMAIL PROTECTED]> writes:
>> For that matter, do you still see dups if you prevent use of the index
>> in the 8.2.5 query? Maybe it's that index that is corrupt.
> Unfortunately, I'm not able to test that at this point.
> To get our production db (the 8.2.5 instance) back in operat
On Nov 6, 2007 11:16 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > However running the same query on the original 8.2.4 database returns
> zero
> > rows:
>
> > prod_1=> select page_id, count(*) from topic_version_page where
> > topic_version_id = 263 group
"Mason Hale" <[EMAIL PROTECTED]> writes:
> However running the same query on the original 8.2.4 database returns zero
> rows:
> prod_1=> select page_id, count(*) from topic_version_page where
> topic_version_id = 263 group by 1 having count(*) > 1;
> page_id | count
> -+---
> (0 rows
The following bug has been logged online:
Bug reference: 3724
Logged by: Mason Hale
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Redhat Linux (kernel: Linux 2.6.18-8.1.15.el5PAE)
Description:Duplicate values added to table despite uniqu
