Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) |
Date | |
Msg-id | 19288.1354230030@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) (Noah Misch <noah@leadboat.com>) |
List | pgsql-hackers |
Noah Misch <noah@leadboat.com> writes: > Linux enforces a hard limit matching the static buffer in sockaddr_un. You'd > proceed a bit further and hit "could not bind Unix socket: Invalid argument" > or some such. Hm, I was wondering about that. The Single Unix Spec suggests that bind/connect ought to accept pathnames at least up to PATH_MAX, but if popular implementations don't honor that then it is a bit pointless for us to do a lot of pushups in userspace. > I agree we should perhaps fix pg_upgrade to work even when its CWD is not > usable as a socket path. It could create a temporary directory under /tmp and > place the socket there, for example. Yeah, I was starting to think that pg_upgrade's test script is the real culprit here. Every other variant of "make check" just puts the socket in the default place, typically /tmp, so it's rather useless that this one place is doing things differently. Another thing that we should possibly consider if we're going to hack on that is that "make check" is not currently very friendly to people who try to move the default socket location to someplace other than /tmp, such as the ever-popular /var/run/postgresql. The reason that this is problematic is that /var/run/postgresql may not be there at all in a build environment, and if it is, it's likely not writable by the user you're running your build as. So just using the default socket directory isn't real friendly in any case. In converting the Fedora packages to use /var/run/postgresql recently, I found I had to add the attached crude hacks to support running the regression tests during build. It'd be nice if the consideration were handled by unmodified sources ... regards, tom lane diff -Naur postgresql-9.2.0.sockets/contrib/pg_upgrade/test.sh postgresql-9.2.0/contrib/pg_upgrade/test.sh --- postgresql-9.2.0.sockets/contrib/pg_upgrade/test.sh 2012-09-06 17:26:17.000000000 -0400 +++ postgresql-9.2.0/contrib/pg_upgrade/test.sh 2012-09-06 18:13:18.178092176 -0400 @@ -62,10 +62,14 @@rm -rf "$logdir"mkdir "$logdir" +# we want the Unix sockets in $temp_root +PGHOST=$temp_root +export PGHOST +set -x$oldbindir/initdb -$oldbindir/pg_ctl start -l "$logdir/postmaster1.log" -w +$oldbindir/pg_ctl start -l "$logdir/postmaster1.log" -o "-c unix_socket_directories='$PGHOST'" -wif "$MAKE" -C "$oldsrc"installcheck; then pg_dumpall -f "$temp_root"/dump1.sql || pg_dumpall1_status=$? if [ "$newsrc" != "$oldsrc"]; then @@ -108,7 +112,7 @@pg_upgrade -d "${PGDATA}.old" -D "${PGDATA}" -b "$oldbindir" -B "$bindir" -pg_ctl start -l "$logdir/postmaster2.log" -w +pg_ctl start -l "$logdir/postmaster2.log" -o "-c unix_socket_directories='$PGHOST'" -wif [ $testhost = Msys ] ; then cmd /c analyze_new_cluster.bat diff -Naur postgresql-9.2.0.sockets/src/test/regress/pg_regress.c postgresql-9.2.0/src/test/regress/pg_regress.c --- postgresql-9.2.0.sockets/src/test/regress/pg_regress.c 2012-09-06 17:26:17.000000000 -0400 +++ postgresql-9.2.0/src/test/regress/pg_regress.c 2012-09-06 18:13:18.184092537 -0400 @@ -772,7 +772,7 @@ if (hostname != NULL) doputenv("PGHOST", hostname); else - unsetenv("PGHOST"); + doputenv("PGHOST", "/tmp"); unsetenv("PGHOSTADDR"); if (port != -1) { @@ -2233,7 +2233,7 @@ */ header(_("starting postmaster")); snprintf(buf, sizeof(buf), - SYSTEMQUOTE "\"%s/postgres\" -D \"%s/data\" -F%s -c \"listen_addresses=%s\" > \"%s/log/postmaster.log\"2>&1" SYSTEMQUOTE, + SYSTEMQUOTE "\"%s/postgres\" -D \"%s/data\" -F%s -c \"listen_addresses=%s\" -c \"unix_socket_directories=/tmp\"> \"%s/log/postmaster.log\" 2>&1" SYSTEMQUOTE, bindir, temp_install, debug ? " -d 5" : "", hostname ? hostname : "",
pgsql-hackers by date: