From: | "Brian Hirt" <bhirt(at)mobygames(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Brian A Hirt" <bhirt(at)berkhirt(dot)com> |
Subject: | Re: problems with table corruption continued |
Date: | 2001-12-18 17:36:28 |
Message-ID: | 017401c187ea$88ce4100$640b0a0a@berkhirt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Yes, both tables had similiar functions, and the corruption was limited to
only those two tables.
----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Brian Hirt" <bhirt(at)mobygames(dot)com>
Cc: "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org>; "Brian A Hirt"
<bhirt(at)berkhirt(dot)com>
Sent: Tuesday, December 18, 2001 11:53 AM
Subject: Re: [HACKERS] problems with table corruption continued
> "Brian Hirt" <bhirt(at)mobygames(dot)com> writes:
> > Great, I'm also trying to create a reproducable test case for the
original
> > problem i reported with duplicate rows/oids/pkeys. Maybe both problems
are
> > a result of the same bug; i don't know.
>
> Were the duplicate rows all in tables that had functional indexes based
> on functions similar to developer_aka_search_name? The problem we're
> seeing here seems to be due to VACUUM not being able to cope with the
> side effects of the SELECT inside the index function.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-18 17:52:28 | Re: problems with table corruption continued |
Previous Message | Brian Hirt | 2001-12-18 17:35:22 | Re: problems with table corruption continued |