On 5/3/2010 9:44 PM, Tom Lane wrote:
> 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
>
How about building a statically linked psql in 'make check', just for
pg_regress to use?
-Andy
