| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | michael(at)synchronicity(dot)com |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: vacuum analyze corrupts database |
| Date: | 2003-05-24 04:52:46 |
| Message-ID: | 6831.1053751966@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Brusser <michael(at)synchronicity(dot)com> writes:
> I should've done already - I loaded this table into another
> instance of the database and I could not reproduce the problem!
Hm. The log looks like the crash is occurring during planning (since
you get a "parse tree" message but no "ProcessQuery"). I'm guessing
that some selectivity-estimation operation that tries to use the
pg_statistic entries generated by VACUUM ANALYZE is failing. Can't
narrow it down further than that though. Again, how about a debugger
stack trace? Also, the pg_stats rows for the table would be interesting.
> If you're willing to look farther I could tar/zip the db as well.
Waste of time, likely, since I don't have a Solaris system to install it
on.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Galbavy | 2003-05-24 10:54:37 | Re: 500 tpsQL + WAL log implementation |
| Previous Message | Bruce Momjian | 2003-05-24 04:40:12 | Re: 500 tpsQL + WAL log implementation |