Re: 7.4 compatibility question

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: 7.4 compatibility question
Дата
Msg-id 200310231633.h9NGXYk24552@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: 7.4 compatibility question  (Michael Brusser <michael@synchronicity.com>)
Ответы Re: 7.4 compatibility question  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Michael Brusser wrote:
> > -----Original Message-----
> > From: Bruce Momjian 
> ...
> > The big question is whether the current release notes hit he right
> > balanced.  Do they for you?
> 
> The last time I read the notes was when we upgraded to 7.3.4.
> I'll pick up couple entries from Release Notes and the HISTORY file
> (which we always read) for examples.
> 
> PostgreSQL now supports the ALTER TABLE ... DROP COLUMN functionality. 
>  => this is entirely sufficient. Detailed info can be found in the docs.

Good.

> Optimizer improvements
>  => this tells me nothing. I suppose this could be a minor internal code
> tweak, which does not affect me. On the other hand this could be a major
> breakthrough, so now I can run some stupid query which would take
> a week to complete in the previous release. How do I know? 

Yes, this is always very hard to explain. The optimizer itself is
complex, and uses complex terms like merge join and key pruning.  It is
hard to explain what queries will be affected, though the basic issue is
that the optimizer will choose a better plan more frequently.

> Fix to_ascii() buffer overruns
>  => I don't think I need any more details here
> 
> Work around buggy strxfrm() present in some Solaris releases
>  => if we did not suffer from this (big thanks for fixing!) I would've
> never guessed how it may manifest itself and affect the database,
> even though this alone could be a strong reason for upgrade.

We don't actually explain enough in the release notes for people to
determine if they should do _minor_ upgrades --- bottom line is that
minor upgrades only require a stop/install/restart postmaster, so we
assume everyone will do that, and in this case, if you are running
Solaris, that is enough of a reason alone --- whether that particular
bug affects you or not.

> If you think this would take too much space and bloat the document,
> then maybe the best solution is to have a reference number:
>  Bug# 123 : Work around ...
> Then I could go to some http://postgres../bugtrack enter this number
> and learn more.

Yes, that would be nice.

So, it sounds like we are already pretty close to ideal for you.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: pg_ctl reports succes when start fails
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Last beta ... we hope?