Thread: Yet another issue with pg_upgrade vs unix_socket_directories
I went back for another try at building the Fedora packages with 9.2
branch tip ... and it still failed at pg_upgrade's "make check".
The reason for this is that test.sh starts a couple of random
postmasters, and those postmasters expect to put their sockets in
the configured default location (which is now /var/run/postgresql
on Fedora), and that's not there in a minimal build environment.
I hacked it up with the attached quick-and-dirty patch, but I wonder
if anyone's got a better idea.
regards, tom lane
diff --git a/contrib/pg_upgrade/test.sh b/contrib/pg_upgrade/test.sh
index 31e30af..c00aa98 100644
*** a/contrib/pg_upgrade/test.sh
--- b/contrib/pg_upgrade/test.sh
*************** logdir=$PWD/log
*** 60,69 ****
rm -rf "$logdir"
mkdir "$logdir"
set -x
$oldbindir/initdb
! $oldbindir/pg_ctl start -l "$logdir/postmaster1.log" -w
if "$MAKE" -C "$oldsrc" installcheck; then
pg_dumpall >"$temp_root"/dump1.sql || pg_dumpall1_status=$?
if [ "$newsrc" != "$oldsrc" ]; then
--- 60,73 ----
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" -o "-c unix_socket_directories='$PGHOST'" -w
if "$MAKE" -C "$oldsrc" installcheck; then
pg_dumpall >"$temp_root"/dump1.sql || pg_dumpall1_status=$?
if [ "$newsrc" != "$oldsrc" ]; then
*************** initdb
*** 106,112 ****
pg_upgrade -d "${PGDATA}.old" -D "${PGDATA}" -b "$oldbindir" -B "$bindir"
! pg_ctl start -l "$logdir/postmaster2.log" -w
sh ./analyze_new_cluster.sh
pg_dumpall >"$temp_root"/dump2.sql || pg_dumpall2_status=$?
pg_ctl -m fast stop
--- 110,116 ----
pg_upgrade -d "${PGDATA}.old" -D "${PGDATA}" -b "$oldbindir" -B "$bindir"
! pg_ctl start -l "$logdir/postmaster2.log" -o "-c unix_socket_directories='$PGHOST'" -w
sh ./analyze_new_cluster.sh
pg_dumpall >"$temp_root"/dump2.sql || pg_dumpall2_status=$?
pg_ctl -m fast stop
On 9/3/12 5:00 PM, Tom Lane wrote: > I went back for another try at building the Fedora packages with 9.2 > branch tip ... and it still failed at pg_upgrade's "make check". > The reason for this is that test.sh starts a couple of random > postmasters, and those postmasters expect to put their sockets in > the configured default location (which is now /var/run/postgresql > on Fedora), and that's not there in a minimal build environment. And if it's there, it might not be writable. > I hacked it up with the attached quick-and-dirty patch, but I wonder > if anyone's got a better idea. Yeah, I have resorted to putting something like export PGHOST=/tmp in all my test scripts, because the above-mentioned issues have affected Debian for a long time. Welcome to the party. ;-) It might actually be useful if the postmaster accepted PGHOST as the default value for the -k option, just like it accepts PGPORT. Then this type setup will become much easier because clients and servers will use the same defaults.
On Tue, Sep 4, 2012 at 01:44:59PM -0400, Peter Eisentraut wrote: > On 9/3/12 5:00 PM, Tom Lane wrote: > > I went back for another try at building the Fedora packages with 9.2 > > branch tip ... and it still failed at pg_upgrade's "make check". > > The reason for this is that test.sh starts a couple of random > > postmasters, and those postmasters expect to put their sockets in > > the configured default location (which is now /var/run/postgresql > > on Fedora), and that's not there in a minimal build environment. > > And if it's there, it might not be writable. > > > I hacked it up with the attached quick-and-dirty patch, but I wonder > > if anyone's got a better idea. > > Yeah, I have resorted to putting something like > > export PGHOST=/tmp > > in all my test scripts, because the above-mentioned issues have affected > Debian for a long time. Welcome to the party. ;-) > > It might actually be useful if the postmaster accepted PGHOST as the > default value for the -k option, just like it accepts PGPORT. Then this > type setup will become much easier because clients and servers will use > the same defaults. Interesting idea, but PGPORT controls both the tcp and unix domain socket connections. Wouldn't PGHOST just control just unix domain? Is that logical? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Peter Eisentraut <peter_e@gmx.net> writes:
> Yeah, I have resorted to putting something like
> export PGHOST=/tmp
> in all my test scripts, because the above-mentioned issues have affected
> Debian for a long time. Welcome to the party. ;-)
Yeah, my current patch for Fedora does exactly that in pg_regress, and
has it force the test postmaster's unix_socket_directory as well.
The problem with pg_upgrade's shell script is that it's not going
through pg_regress: it launches some test postmasters directly, and
also fires up psql etc directly. So it needs its own fix for this.
> It might actually be useful if the postmaster accepted PGHOST as the
> default value for the -k option, just like it accepts PGPORT. Then this
> type setup will become much easier because clients and servers will use
> the same defaults.
Cute idea, but it'll fall down rather badly if PGHOST is a hostname...
There's no time to redesign this stuff for 9.2, but now that I've had
some exposure to the testing difficulties created by a nonstandard
default socket directory, I'm more interested in trying to fix these
issues in core.
regards, tom lane