"Paul B. Anderson" <[EMAIL PROTECTED]> writes:
> I have a cluster of machines and the databases are on shared disk
> storage. I'm just getting this arrangement working and, while I've been
> debugging my scripts, I've accidentally had two copies of postgresql
> running against the same initdb d
Here are a couple of new data points on this issue.
Deleting all records in pg_statistic and then reindexing clears the
problem but I've had the problem in two of my own databases in two
separate postgresql instances as well as the postgres database in both
instances.
I have a cluster of ma
andy <[EMAIL PROTECTED]> writes:
> So I'm ok, but I tried it again, by dropping the database and re-running
> both scripts and got the same error again. So thought I'd offer a test
> case if there was interest.
Absolutely. I've seen just enough of these reports to make me think
there's an unde
Tom Lane wrote:
"Paul B. Anderson" <[EMAIL PROTECTED]> writes:
I did delete exactly one of each of these using ctid and the query then
shows no duplicates. But, the problem comes right back in the next
database-wide vacuum.
That's pretty odd --- I'm inclined to suspect index corruption.
I
I removed the duplicates and then immediately reindexed. All is
well. The vacuum analyze on the postgres database works now too.
Thanks.
It is good to know the pg_statistic table can be emptied in case this
ever happens again.
Paul
Tom Lane wrote:
"Paul B. Anderson" <[EMAIL PROTECTED]>
"Paul B. Anderson" <[EMAIL PROTECTED]> writes:
> I did delete exactly one of each of these using ctid and the query then
> shows no duplicates. But, the problem comes right back in the next
> database-wide vacuum.
That's pretty odd --- I'm inclined to suspect index corruption.
> I also tried r
