Re: Yet another failure mode in pg_upgrade

On Sun, Sep 2, 2012 at 01:13:52PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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.

Well, I don't know of any known problems with the patch. On the other
hand, I don't know our policy in pushing patches into RC releases at the
request of packagers.

If you want to stand behind the patch, it might be OK. I think that's
how we handle such requests --- someone has to put their neck out for
it. Fortunately the patch is not very large so is easy to review.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +