View oddness...

From: Michael Richards <miker(at)scifair(dot)acadiau(dot)ca>
To: pgsql-bugs(at)postgreSQL(dot)org
Subject: View oddness...
Date: 1999-08-11 02:53:24
Message-ID: Pine.BSF.4.10.9908102345590.75044-100000@scifair.acadiau.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi.
I've noticed one of my views decided to grow a mind of it's own...

fastmail=> \d validusers
View = validusers
Query = SELECT "loginid", "datecreated", "lastused" FROM "users" WHERE
"enabled" = 't'::"bool";
+----------------------------------+----------------------------------+------+
| Field | Type |Length|
+----------------------------------+----------------------------------+------+
| loginid | varchar() |16|
| datecreated | datetime | 8|
| lastused | timestamp | 4|
+----------------------------------+----------------------------------+--+
fastmail=> select count(*) from users;
count
-----
32620
(1 row)

fastmail=> select count(*) from validusers;
count
-----
41670
(1 row)

validusers claims to have more rows than what it came from...

This all comes from the server being power cycled which corrupted the
users table. We dropped and re-created the users table because it refused
to vacuum.

fastmail=> vacuum users;
NOTICE: Index users_pkey: NUMBER OF INDEX' TUPLES (3212) IS NOT THE SAME
AS HEAP' (4246)
ERROR: Cannot insert a duplicate key into a unique index

The part I can't figure out is why a view (which is supposed to come from
a select) was affected...

Having given this some thought, would it be possible to add a switch to
vacuum, ie vacuum check that would check the integrity of a table and
repair it if there are problems?

-Michael

Browse pgsql-bugs by date

  From Date Subject
Next Message Christof Petig 1999-08-11 08:41:35 ecpg generates illegal code, patch included
Previous Message Nikolay Grigoriev 1999-08-09 20:31:23 bug report