Tom,
> I don't believe a single word of that explanation ... whatever is
> going
> on here, that ain't it. A new table is going to have a new OID, and
> so will its indexes; there is no way that Postgres will confuse it
> with
> the old one, even if bits of the old one were still hanging around
> somehow (which I don't believe either).
You're the expert. All I know for a fact is that when I didn't
explicitly drop the indexes, I got weird results; when I did explicitly
drop them, I didn't.
The whole system is complex enough that the problem is hard to reproduce
without reproducing the whole system (which I'd be happy to do for you,
only it contains confidential data). From the sound of it, I'm the only
one who's encountered this.
> One thing to think about, if you are dropping and recreating tables
> in
> a plpgsql function, is that you probably need to do it with EXECUTE
> to avoid plan caching.
OK. Will do. Thanks. This may also cure the intermittent
index/whatever issue.
> Not unless your kernel or hardware are broken. But I have seen cases
> where hardware problems (eg, bogus DMA controller) manifested
> themselves
> only as database errors. Evidently Postgres was pushing the disk
> harder
> than anything else on the system, so it was more likely to get bit by
> a sporadic hardware booboo.
Thanks!
-Josh
