vacuumdb is failing with NUMBER OF INDEX TUPLES NOT THE SAME AS HEAP

Greetings,
I've got an annoying problem. I'm currently running PostgreSQL-7.3.4
on Linux (x86). This problem started with 7.3.3. I've got a database
that is on the larger side (about 3GB dump). I run "vacuumdb -z -a
-f" religiously via a cronjob three times a day.

All of a sudden last month (after about 3 years) I started getting
this warning when vacuumdb was run:

INFO: Index pg_largeobject_loid_pn_index: Pages 903; Tuples 323847:
Deleted 0. CPU 0.04s/0.07u sec elapsed 0.10 sec.
WARNING: Index pg_largeobject_loid_pn_index: NUMBER OF INDEX' TUPLES
(323847) IS NOT THE SAME AS HEAP' (323802).
Recreate the index.

So I put postgresql into standalone mode, recreated the index, and
everything was ok for about 2 days, and then the problem would return.
I did some Googling and found that this was a potential bug in older
versions of postgresql, but was supposedly fixed in 7.3.4 and later
versions. So I upgraded to 7.3.4 (using the semi-official RPMs on the
postgresql.org ftp servers). Dropped into standalone mode, reindexed,
and everything was fine for about the past month.

Until this morning when it came back again. The server where this is
running isn't having any hardware problems, isn't getting shutdown
improperly or anything like that. Its current uptime is 209 days, and
postgresql is never shutdown improperly.

Now I'd be willing to upgrade further, but I really can't afford
unnecessary downtime. So I'd like some guidance/input on which
version of postgresql will not have this bug. Or maybe this isn't the
bug at all, and there's some other weird problem?

Either way, any and all advice is appreciated.

Thanks!
Lonni