| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Patrick Boake <pboake(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #9416: Setting up postgresql-9.1 (9.1.12-0wheezy1) Fails Configuration |
| Date: | 2014-03-03 23:52:42 |
| Message-ID: | 20401.1393890762@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-03-03 16:28:21 -0500, Tom Lane wrote:
>> Right now, you only get a failure of the pgstats subsystem, which is
>> logged. I don't think we can do much more than that unless you want
>> to make it a postmaster-refuses-to-start case, which seems like not
>> a net improvement.
> I'd actually say that'd be an improvement. I've, a long time ago, spent
> several hours debugging a case of this, it's nontrivial for a
> beginner. And a normal PG install simply won't work properly without
> pgstat these days, so refusing to startup seems reasonable.
I still don't much like refusing to start.
Perhaps we should reconsider the idea of just hardwiring "127.0.0.1" and
the corresponding IPv6 locution into pgstats? Or maybe better, hard-wire
trying those if "localhost" fails to resolve.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Venkata Balaji Nagothi | 2014-03-03 23:55:53 | Re: BUG #9424: Database size increased by 10MB everyday |
| Previous Message | maxim.boguk | 2014-03-03 23:36:16 | BUG #9430: Strange error during pg_dump with concurrent alter table working |