Re: Noah Misch 2014-03-30 <20140330014531.ge170...@tornado.leadboat.com> > On Sat, Mar 29, 2014 at 10:04:55AM +0100, Christoph Berg wrote: > > Fwiw, to relocate the pg_regress socket dir, there is already the > > possibility to run make check EXTRA_REGRESS_OPTS="--host=/tmp". (With > > the pending fix I sent yesterday to extend this to contrib/test_decoding.) > > That doesn't work for "make check", because the postmaster ends up with > "listen_addresses=/tmp".
Oh, right. There's this other patch which apparently works so well that I already forgot it's there: Enable pg_regress --host=/path/to/socket: https://alioth.debian.org/scm/loggerhead/pkg-postgresql/postgresql-9.4/trunk/view/head:/debian/patches/60-pg_regress_socketdir.patch This, along with 61-extra_regress_opts and 64-pg_upgrade-sockdir (at the same location, both also recently posted here) should be safe for general use, i.e. inclusion in git. (I didn't check how much this overlaps with what Noah tried, I'm just mentioning the patches here because they work for Debian.) There's two other patches: 62-pg_upgrade-test-in-tmp hardcodes /tmp for the pg_upgrade test which should obviously be done smarter, and 63-pg_upgrade-test-bindir which forwards PSQLDIR through contrib/pg_upgrade/test.sh. The latter is probably also safe for general use, but I'd be more confident if someone rechecked that. > > We've been putting a small patch into pg_upgrade in Debian to work > > around too long socket paths generated by pg_upgrade during running > > the testsuite (and effectively on end user systems, but I don't think > > anyone is using such long paths there). > > > > A similar code bit could be put into pg_regress itself. > > Thanks for reminding me about Debian's troubles here. Once the dust settles > on pg_regress, it will probably make sense to do likewise to pg_upgrade. Nod, it'd be nice if we could get rid of some patches in Debian. Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers