| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: strange buildfarm failure on lionfish |
| Date: | 2007-07-25 17:02:06 |
| Message-ID: | 24425.1185382926@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Maybe what we could do is set higher thresholds for the regression
>> database with ALTER DATABASE.
> That seems to make sense at least as a short-term response.
I tried this, and it crashed and burned:
ERROR: parameter "autovacuum_analyze_threshold" cannot be changed now
because the autovac parameters are marked PGC_SIGHUP so that they
can only be adjusted from postgresql.conf.
Someday we might like to allow this, but it seems to mean inventing a
new GUC context type, which I don't think I want to get into right now.
For the moment I guess the answer is to change the horology test case.
As far as I've seen, we have seen no other failures than that, so my
worry about autovac impacting other test cases may be overblown.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Wong | 2007-07-25 17:09:31 | Re: Machine available for community use |
| Previous Message | Simon Riggs | 2007-07-25 16:58:42 | Re: Machine available for community use |