[blfs-dev] postgresql, and policy

Ken Moffat zarniwhoop at ntlworld.com
Thu Sep 12 15:37:02 PDT 2013

On Thu, Sep 12, 2013 at 04:17:17PM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> > On Thu, Sep 12, 2013 at 08:25:00PM +0100, Ken Moffat wrote:
> >>   I've now got the postgresql testsuite working for a normal user,
> >> using the attached patch (based on gentoo, but simplified - they
> >> make one other change, which seems unnecessary, and use @SOCKETDIR@
> >> then sed that to /tmp after applying the patch.
> >>
> I think my first sed is a little shorter and easier to understand.  The 
> results are the same.
> >   Really attached, in case we come back to this method.

 The probable reason why your method worked for you, but not for me,
came to me while I was making my dinner : you are using a 3.10
kernel, my machine where I tested is using 3.11.0.  I've just tested
on my i686 which is running 3.10.10 and your method works there (I
still don't like adding the user if the machine is only going to be
a postgres client, but I could live with that and probably take
remedial action in my own builds).

 Whether 3.11.{1...x} will show the same behaviour as 3.10.10, or
indeed whether 3.10.largenumber will show the behaviour of 3.11, I
have no idea.  This isn't something I've got the neck to ask about
on the kernel lists (first, git bisect to find which patch to blame,
then explain (and I think I can guess who to) that "yes, we are
changing upstream's 'put the socket in /tmp' but we don't want to
apply patches to fix the testsuite to support that."

> Would the following work for the patch?
> sed -i -e 's at psql\\"@& -h /tmp@' src/test/regress/pg_regress{,_main}.c
> sed -i -e 's at gres\\"@& -h /tmp@' src/test/regress/pg_regress.c
> The following might also work (not checked):
> sed -i -r 's@(psql|gres)\\"@& -h /tmp@' \
>      src/test/regress/pg_regress{,_main}.c
>    -- Bruce

 Not quite : need to add -k not -h for 'gres'.  I'll take a look in
a little while.

das eine Mal als Tragödie, dieses Mal als Farce

More information about the blfs-dev mailing list