Re: Yet another failure mode in pg_upgrade
От | Tom Lane |
---|---|
Тема | Re: Yet another failure mode in pg_upgrade |
Дата | |
Msg-id | 25531.1346606032@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 Sun, Sep 2, 2012 at 01:06:28AM -0400, Robert Haas wrote: >> I don't think this is reducing the number of failure modes; it's just >> changing it from one set of obscure cases to a slightly different set >> of obscure cases. > Tom reported problems with having old/new with different default socket > locations. This fixes that, and reduces the possibility of acciental > connections. What problems does this add? I'm going to be needing some fix in this area in any case, though whether it's exactly Bruce's current patch is not clear to me. I found out last night while making a test build of 9.2rc1 as a Fedora package that pg_upgrade's regression test fails in the Fedora build environment, if the postmaster has been patched so that its default socket directory is /var/run/postgresql. That happens because /var/run/postgresql doesn't exist in the build environment (it is only going to exist once the postgresql-server package is installed), so the postmaster fails to start because it can't create a socket where it expects to. I have a patch to pg_regress that instructs the temporary postmaster to use /tmp as unix_socket_directory regardless of its built-in default, so that "make check" works for the regular core and contrib regression tests. However, that doesn't affect pg_upgrade's regression test case. It looks rather messy to persuade pg_upgrade to do things differently for regression testing and normal use, not to mention that it would make the test even less representative of normal use. So I'm thinking that we do need the pg_upgrade feature Bruce is suggesting of forcing the socket directory to be the current directory. What's more, if that's not back-patched to 9.2, I'm going to have to carry it as a Fedora patch anyway. Alternatively, I can prevent "make check" from testing pg_upgrade (which is what I did so I could carry on with package testing). I'd just as soon not ship it like that, though. regards, tom lane
В списке pgsql-hackers по дате отправления: