Re: Yet another failure mode in pg_upgrade
| От | Tom Lane |
|---|---|
| Тема | Re: Yet another failure mode in pg_upgrade |
| Дата | |
| Msg-id | 25927.1346683358@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Yet another failure mode in pg_upgrade (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: Yet another failure mode in pg_upgrade
|
| Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> writes:
> On Mon, Sep 3, 2012 at 10:07:43AM -0400, Tom Lane wrote:
>> It's not necessary, no? The code now gets socket directory right
>> without help.
> Well, the doc comment is:
> + If running check on an old pre-9.1 Unix-like running server, and the
> + old and new servers use different Unix-domain socket directories,
> + use the <option>-O</> option so the new server uses the same socket
> + directory as the old server, and set <envar>PGHOST</> similarly.
> Remember, we can't get the socket directory for pre-9.1 servers.
Yeah, but even if you assume that pg_upgrade needs help for that, this
doc is wrong and overcomplicated. The case that would be problematic
is where the old server is running with a unix_socket_directory that
is not the same as the default built into pg_upgrade's libpq. It is
not necessary (given my patch) that the new server match that socket
directory. What is necessary is that pg_upgrade be able to contact
the old server. I think, but haven't tested, that it's sufficient
to set PGHOST to make that work. The patched code will override
PGHOST for the new cluster anyway, since it will always specify
--host as the new-cluster socket directory.
regards, tom lane
В списке pgsql-hackers по дате отправления: