| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files) |
| Date: | 2010-11-22 17:30:20 |
| Message-ID: | 29474.1290447020@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I don't see why an upgrading aid would be worthy of back-patching, but
> not a debugging aid. I'd certainly prioritize those in the other
> order.
I think the sort of upgrading aid Peter has in mind is the kind where
it's entirely useless if it's not back-patched, because it has to run in
the pre-upgraded server. We've discussed such things before in the
context of in-place upgrade, though I believe there have been no actual
instances as yet.
I'm not really sure why we're even considering the notion of
back-patching this item. Doing so would not fit with any past practice
or agreed-on project management practices, not even under our lax
standards for contrib (and I keep hearing people claim that contrib
is or should be as trustworthy as core, anyway). Since when do we
back-patch significant features that have not been through a beta test
cycle?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2010-11-22 17:40:35 | Re: dblink versus long connection strings |
| Previous Message | Tom Lane | 2010-11-22 17:21:36 | Re: dblink versus long connection strings |