I wrote:
> I'd have thought that pg_regress would have a more obvious failure if it
> was trying to use an old libpq.so version though --- it should have
> looked similar to what you referenced for pg_dump, for instance.
I think I see what's going on here. pg_regress itself doesn't link to
libpq at all. psql uses some of the new functions that were added to
libpq in 9.0, so psql is guaranteed to fail if the linker tries to link
it to an 8.4 version of libpq, which is probably what was happening
before you did "make install". The reason that this led to the observed
behavior is that pg_regress does this to see if the postmaster is
running yet:
if (system("psql ... 2>/dev/null") == 0)
// postmaster is ready
else
// keep waiting
So psql failed, spewed something to stderr that went right into the bit
bucket, and pg_regress just saw that as an expected failure and kept
waiting.
I'm not immediately seeing a simple way to improve this. It'd be nice
if we didn't hide "unexpected" errors like the link failure with libpq.
On the other hand we surely don't want to show the expected connection
failures until the postmaster is up. Maybe psql should have a "really
quiet" mode that doesn't print anything even on errors, and then we
wouldn't have to route its stderr to /dev/null? But given how seldom
this sort of thing comes up (I don't recall any similar previous reports,
actually) maybe it's not worth the trouble.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
