[HACKERS] Weird ecpg failures on buildfarm NetBSD members
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=salamanderdt=2007-07-08%2017:30:00 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=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? I don't really have time to investigate this, but would like to know what happened. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Weird ecpg failures on buildfarm NetBSD members
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=salamanderdt=2007-07-08%2017:30:00 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=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.70 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Weird ecpg failures on buildfarm NetBSD members
Kris Jurka [EMAIL PROTECTED] writes: On Mon, 9 Jul 2007, Tom Lane wrote: Today's puzzler for the curious: It turns out that this failure was caused by pulling in pg's own printf implementation to the resulting ECPG program. Hah! Nice detective work, Kris. Calling printf(%.*f\n, -1, 14.7) results in 14 from pg_printf and 14.70 from NetBSD's. So does this represent a bug or shortcoming in pg_printf? A quick look at the spec says that A negative precision is taken as if the precision were omitted, and rounding to int doesn't sound like the appropriate behavior for bare %f. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
