Re: pg_standby for 8.2 (with last restart point)
От | Gurjeet Singh |
---|---|
Тема | Re: pg_standby for 8.2 (with last restart point) |
Дата | |
Msg-id | 65937bea0803272200u19d27d7eree4873f1f21f9d16@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_standby for 8.2 (with last restart point) (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: pg_standby for 8.2 (with last restart point)
|
Список | pgsql-hackers |
On Fri, Mar 28, 2008 at 9:47 AM, Greg Smith <gsmith@gregsmith.com> wrote:
Point well taken. And when I said 'I completely understand that', I meant I understood Postgres' policy for patching older releases. And thanks for the links; it feels good to know that there's an "official" stand on this topic in Postgres, rather than 'no known serious bugs'. :)
I am still looking for comments on the correctness of this script and above mentioned procedure for running it on an 8.2.x release.
Thanks and best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
Mail sent from my BlackLaptop device
On Fri, 28 Mar 2008, Gurjeet Singh wrote:>> This project doesn't make functional changes to stable releases, that'sWell, then you really don't understand this at all then, so let's work on
>> the reason why 8.2 will never get patched to add the %r feature.
> I completely understand that, but still was hoping that we'd change that.
that for a bit. http://www.postgresql.org/support/versioning is the
official statement, perhaps some examples will help clarify where and why
the line is where it is.
One of the first patches I ever submitted made a minor change to a contrib
utility used solely for benchmarking (pgbench) that added a useful
feature, only if you passed it the right parameter. That was considered
for a tiny bit before being rejected as a feature change too large to put
into a stable branch.
That was a small change in a utility that should never be run on a
production system. You're trying to get a change made to the code path
people rely on for their *backups*. Good luck with that.
The parable I enjoy pulling out in support of this policy is MySQL bug
#31001:
http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/
where they added a seemingly minor optimization to something and
accidentally broke the ability to sort in some cases. There's always a
small risk that comes with any code change, and this is why you don't ever
touch working production code unless you're fixing a bug that's more
troublesome than that risk.
Point well taken. And when I said 'I completely understand that', I meant I understood Postgres' policy for patching older releases. And thanks for the links; it feels good to know that there's an "official" stand on this topic in Postgres, rather than 'no known serious bugs'. :)
I am still looking for comments on the correctness of this script and above mentioned procedure for running it on an 8.2.x release.
Thanks and best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
Mail sent from my BlackLaptop device
В списке pgsql-hackers по дате отправления: