Re: [HACKERS] v10 pg_ctl compatibility

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [HACKERS] v10 pg_ctl compatibility
Дата
Msg-id CAMkU=1wi_x7m90-nz4sZOCuww=bMrEWG2onzc7+nxBgA3Oq+qw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] v10 pg_ctl compatibility  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] v10 pg_ctl compatibility  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Дерево обсуждения
On Tue, Sep 26, 2017 at 12:29 PM, Andres Freund <andres@anarazel.de> wrote:
Hi,

On 2017-09-26 11:59:42 -0700, Jeff Janes wrote:
> Should the release notes have a compatibility entry about pg_ctl restart,
> being used against a running pre-10 server, no longer being able to detect
> when startup is complete?
>
> I don't know if cross-version use of pg_ctl restart was ever officially
> supported, but the current behavior is rather confusing (waiting for a long
> time, and then reporting failure, even though it started successfully).

I'm actually tempted to just make pg_ctl verify the right version of
postgres is being used. Maybe I'm missing something, but what's the
use-case for allowing it, and every couple releases have some breakage?

The use case for me is that I have multiple versions of postgres running on the same machine, and don't want check which pg_ctl is in my path each time I change one of their configurations and need to restart it.  Or at least, I never had to check before, as pg_ctl goes out of its way to restart it with the same bin/postgres that the server is currently running with, rather than restarting with the bin/postgres currently in the path, or whichever bin/postgres is in the same directory as the bin/pg_ctl.  (Which is itself not an unmitigated win, but it is what I'm used to).

Admittedly, this is a much bigger problem with hacking/testing than it is with production use, but still I do have production machines with mixed versions running, and can see myself screwing this up a few times once one of them gets upgraded to v10, even with an incompatibility warning in the release notes.  But at least I had fair warning.

To add insult to injury, when v10 pg_ctl does restart a pre-10 server and it sits there for a long time waiting for it to start up even though it has already started up, if I hit ctrl-C because I assume something is horribly wrong, it then goes ahead and kills the successfully started-and-running server.

If we do want to do a version check and fail out, I think it should check before shutting it down, rather than shutting it down and then refusing to start.

Cheers,

Jeff

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] v10 pg_ctl compatibility
Следующее
От: Peter Geoghegan
Дата:
Сообщение: [HACKERS] Re: Patch to address concerns about ICU collcollate stability in v10(Was: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?)