| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] regression test results - Linux, cvs |
| Date: | 1998-10-29 19:49:36 |
| Message-ID: | 12638.909690576@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
>> btw, vacuum crash when postmaster starts with -B 1024 option
>> seems fixed now !!!! I tried many times 'vacuum analyze' and never
>> get problem ! Probably this is a bonus of last fixes :-)
> My guess is the catalog changes Tom did fixed it. Vacuum analyze uses
> them quite a bit, and buffer cache size could affect which duplicate was
> picked.
Hmm, that would be an unexpected side benefit, wouldn't it! It could be
true, if vacuum depends on pg_operator entries. That'd explain why the
rest of us couldn't duplicate Oleg's problem: I'll bet no one who tried
had tables containing the data types that had bogus entries. (In fact,
I imagine you need to have some *indexes* on those data types before
you'd see such a problem in vacuum, no?)
It occurs to me that there ought to be a VACUUM ANALYZE somewhere in
the regression suite, probably at the end where it has a whole database
of weird stuff to chew on.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jon Buller | 1998-10-29 20:30:02 | NS32K regression test |
| Previous Message | geek+ | 1998-10-29 18:51:05 | Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/include/catalog pg_operator.h' |