| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Going for "all green" buildfarm results |
| Date: | 2006-08-17 13:02:36 |
| Message-ID: | 5207.1155819756@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> maybe the following buildfarm report means that we need a new theory :-(
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=sponge&dt=2006-08-16%2021:30:02
Vacuum's always had a race condition: it makes a list of rel OIDs and
then tries to vacuum each one. It narrows the window for failure by
doing a SearchSysCacheExists test before relation_open, but there's
still a window for failure.
The rel in question is most likely a temp rel of another backend,
because sanity_check is running by itself and so there shouldn't
be anything else happening except perhaps some other session's
post-disconnect cleanup. Maybe we could put the check for "is
this a temp rel of another relation" into the initial list-making
step instead of waiting till after relation_open. That doesn't
seem to solve the general problem though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stefan Kaltenbrunner | 2006-08-17 13:09:03 | Re: Going for "all green" buildfarm results |
| Previous Message | Tom Lane | 2006-08-17 12:54:00 | Re: [PATCHES] WIP: bitmap indexes |