Postgres Pro
Downloads
Home   >   mailing lists

Thread: LibPqEasy, binary cursor, x86-64, fetch(int4) problem?

LibPqEasy, binary cursor, x86-64, fetch(int4) problem?

From
"Mariano Reingart"
Date:
Hi, I recently moved a simple application from a 32bit Intel to a new AMD64 
server (migrated from Postgres 7.2 to 8.1.2 and LibPqEasy 3.0.4), running 
Slamd64 (Slackware port to the AMD64). Everything compiled just fine but the 
applicattion didn't work as expected.
When I look into the tables (with psql) I see strange values in int4 columns 
like ( 16777216, 402653184, 1124073472, ...) instead of normal ones (1, 24, 
67)
Looking at application logs I found that libpqeasy is returning bad values 
in fetch( &int4 ) functions.
Thinking that my code is wrong, I run pginsert example from libpgeasy and it 
didn't work either.
Using text cursors (not binary) and atoi() solved the problem.

Here is a sample code to reproduce the bug, adapted from 
/libpgeasy-3.0.4/examples/pginsert.c:

#include <stdio.h>
#include <unistd.h>
#include "libpq-fe.h"
#include "libpgeasy.h"

int main(void) {   int aint;   char astring[1024];
   connectdb("dbname=fichadas");   on_error_stop();

   doquery("BEGIN WORK");   doquery("CREATE TABLE testfetch(aint int4)");   doquery("INSERT INTO testfetch (aint)
VALUES( 1 )");
 

   /* this will print a strange number like 16777216 instead of 1: */
   doquery("DECLARE c_testfetch BINARY CURSOR FOR SELECT aint FROM 
testfetch WHERE aint=1");   doquery("FETCH ALL IN c_testfetch");
   fetch(&aint);   printf("aint=%d\n",aint);

   /* this will print a correct value: */
   doquery("DECLARE c2_testfetch CURSOR FOR SELECT aint FROM testfetch 
WHERE aint=1");   doquery("FETCH ALL IN c2_testfetch");
   fetch(astring);   printf("atoi(astring)=%d\n",atoi(astring));
   return 0;
}

/* ------------------------------- */

gcc -o test1 test1.c -lpgeasy

Output:

aint=16777216
atoi(astring)=1

Hope this helps,
Regards,
Mariano Reingart

Re: LibPqEasy, binary cursor, x86-64, fetch(int4) problem?

From
Michael Fuhr
Date:
On Sat, Feb 11, 2006 at 08:28:25PM -0300, Mariano Reingart wrote:
> Hi, I recently moved a simple application from a 32bit Intel to a new AMD64 
> server (migrated from Postgres 7.2 to 8.1.2 and LibPqEasy 3.0.4), running 
> Slamd64 (Slackware port to the AMD64). Everything compiled just fine but 
> the applicattion didn't work as expected.
> When I look into the tables (with psql) I see strange values in int4 
> columns like ( 16777216, 402653184, 1124073472, ...) instead of normal ones 
> (1, 24, 67)

Convert the numbers to hex and they don't look so strange:

1  = 0x01
24 = 0x18
67 = 0x43

16777216   = 0x01000000
402653184  = 0x18000000
1124073472 = 0x43000000

That ought to hint at what's happening.

-- 
Michael Fuhr

Re: LibPqEasy, binary cursor, x86-64, fetch(int4) problem?

From
Bruce Momjian
Date:
I am confused by your report.  I assume AMD's still have 32-bit ints, so
it seems it should match the size of int4.  Can you try using aint as a
'long' and using '%ld' to print it and see if that helps?  Are you using
some compile flag to force 64-bit ints?  If so,try using an int8 in the
query and that should work.

---------------------------------------------------------------------------

Mariano Reingart wrote:
> Hi, I recently moved a simple application from a 32bit Intel to a new AMD64 
> server (migrated from Postgres 7.2 to 8.1.2 and LibPqEasy 3.0.4), running 
> Slamd64 (Slackware port to the AMD64). Everything compiled just fine but the 
> applicattion didn't work as expected.
> When I look into the tables (with psql) I see strange values in int4 columns 
> like ( 16777216, 402653184, 1124073472, ...) instead of normal ones (1, 24, 
> 67)
> Looking at application logs I found that libpqeasy is returning bad values 
> in fetch( &int4 ) functions.
> Thinking that my code is wrong, I run pginsert example from libpgeasy and it 
> didn't work either.
> Using text cursors (not binary) and atoi() solved the problem.
> 
> Here is a sample code to reproduce the bug, adapted from 
> /libpgeasy-3.0.4/examples/pginsert.c:
> 
> #include <stdio.h>
> #include <unistd.h>
> #include "libpq-fe.h"
> #include "libpgeasy.h"
> 
> int main(void) {
>     int aint;
>     char astring[1024];
> 
>     connectdb("dbname=fichadas");
>     on_error_stop();
> 
> 
>     doquery("BEGIN WORK");
>     doquery("CREATE TABLE testfetch(aint int4)");
>     doquery("INSERT INTO testfetch (aint) VALUES ( 1 )");
> 
> 
>     /* this will print a strange number like 16777216 instead of 1: */
> 
>     doquery("DECLARE c_testfetch BINARY CURSOR FOR SELECT aint FROM 
> testfetch WHERE aint=1");
>     doquery("FETCH ALL IN c_testfetch");
> 
>     fetch(&aint);
>     printf("aint=%d\n",aint);
> 
> 
>     /* this will print a correct value: */
> 
>     doquery("DECLARE c2_testfetch CURSOR FOR SELECT aint FROM testfetch 
> WHERE aint=1");
>     doquery("FETCH ALL IN c2_testfetch");
> 
>     fetch(astring);
>     printf("atoi(astring)=%d\n",atoi(astring));
> 
>     return 0;
> }
> 
> /* ------------------------------- */
> 
> gcc -o test1 test1.c -lpgeasy
> 
> Output:
> 
> aint=16777216
> atoi(astring)=1
> 
> Hope this helps,
> Regards,
> Mariano Reingart 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
> 

--  Bruce Momjian   http://candle.pha.pa.us SRA OSS, Inc.   http://www.sraoss.com
 + If your life is a hard drive, Christ can be your backup. +