On Sun, Sep 2, 2012 at 01:13:52PM -0400, Tom Lane wrote: > Bruce Momjian <br...@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.
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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
