Re: Weird ecpg failures on buildfarm NetBSD members - Mailing list pgsql-hackers

From Kris Jurka
Subject Re: Weird ecpg failures on buildfarm NetBSD members
Date
Msg-id Pine.BSO.4.64.0707092109550.10221@leary.csoft.net
Whole thread Raw
In response to Weird ecpg failures on buildfarm NetBSD members  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Weird ecpg failures on buildfarm NetBSD members  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Mon, 9 Jul 2007, Tom Lane wrote:

> Today's puzzler for the curious:
>
> Last night the buildfarm reported two ECPG-Check failures
>
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=salamander&dt=2007-07-08%2017:30:00
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canary&dt=2007-07-08%2017:30:01
>
> which promptly went away again.  Judging by the timestamps these must
> have been induced by Joe's PQconnectionUsedPassword() patch and fixed by
> my subsequent tweaking, but how the heck did that result in an ecpg
> failure?  I think that the cause must have had something to do with his
> inclusion of postgres_fe.h into libpq-fe.h, which I took out on the
> grounds that it was an unacceptable pollution of client code namespace.
> But exactly why/how did that break ecpg, and why did the failure only
> manifest on NetBSD machines?
>

It turns out that this failure was caused by pulling in pg's own printf 
implementation to the resulting ECPG program.  The failing test 
(dyntest.pgc) prints its output using:

printf ("%.*f\n", PRECISION, DOUBLEVAR);

Calling printf("%.*f\n", -1, 14.7) results in "14" from pg_printf and 
"14.700000" from NetBSD's.

This would only happen on machines where we don't use the system 
provided printf which is why it was only seen on NetBSD although in could 
have been seen on mingw as well.

Kris Jurka



pgsql-hackers by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: "Running readonly queried on PITR slaves" status update
Next
From: Tom Lane
Date:
Subject: Re: Weird ecpg failures on buildfarm NetBSD members