Thread

  1. SQLDA fix for ECPG

    Boszormenyi Zoltan <zb@cybertec.at> — 2011-11-11T13:36:39Z

    Hi,
    
    I had a report about ECPG code crashing which involved
    a query using a date field. Attached is a one liner fix to make
    the date type's offset computed consistently across
    sqlda_common_total_size(), sqlda_compat_total_size() and
    sqlda_native_total_size().
    
    This must have been a cut and paste bug and is incorrect
    in 9.0.x, 9.1.x and GIT HEAD. It would be nice to have it
    applied before the next point releases come out.
    
    Best regards,
    Zoltán Böszörményi
    
    -- 
    ----------------------------------
    Zoltán Böszörményi
    Cybertec Schönig & Schönig GmbH
    Gröhrmühlgasse 26
    A-2700 Wiener Neustadt, Austria
    Web: http://www.postgresql-support.de
         http://www.postgresql.at/
    
    
  2. Re: SQLDA fix for ECPG

    Michael Meskes <meskes@postgresql.org> — 2011-11-13T13:12:45Z

    > This must have been a cut and paste bug and is incorrect
    > in 9.0.x, 9.1.x and GIT HEAD. It would be nice to have it
    > applied before the next point releases come out.
    
    Applied, thanks for the patch.
    
    Michael
    
    -- 
    Michael Meskes
    Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
    Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
    Jabber: michael.meskes at googlemail dot com
    VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
    
    
  3. Re: SQLDA fix for ECPG

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-11-13T16:27:11Z

    Boszormenyi Zoltan <zb@cybertec.at> writes:
    > I had a report about ECPG code crashing which involved
    > a query using a date field. Attached is a one liner fix to make
    > the date type's offset computed consistently across
    > sqlda_common_total_size(), sqlda_compat_total_size() and
    > sqlda_native_total_size().
    
    Is this really the only issue there?  I notice discrepancies among those
    three routines for some other types too, notably ECPGt_timestamp and
    ECPGt_interval.
    
    			regards, tom lane
    
    
  4. Re: SQLDA fix for ECPG

    Boszormenyi Zoltan <zb@cybertec.at> — 2011-11-14T08:06:30Z

    2011-11-13 17:27 keltezéssel, Tom Lane írta:
    > Boszormenyi Zoltan <zb@cybertec.at> writes:
    >> I had a report about ECPG code crashing which involved
    >> a query using a date field. Attached is a one liner fix to make
    >> the date type's offset computed consistently across
    >> sqlda_common_total_size(), sqlda_compat_total_size() and
    >> sqlda_native_total_size().
    > Is this really the only issue there?  I notice discrepancies among those
    > three routines for some other types too, notably ECPGt_timestamp and
    > ECPGt_interval.
    >
    > 			regards, tom lane
    
    Yes, you are right. For timestamp and interval, the safe alignment is int64.
    Patch is attached.
    
    Best regards,
    Zoltán Böszörményi
    
    -- 
    ----------------------------------
    Zoltán Böszörményi
    Cybertec Schönig & Schönig GmbH
    Gröhrmühlgasse 26
    A-2700 Wiener Neustadt, Austria
    Web: http://www.postgresql-support.de
         http://www.postgresql.at/
    
    
  5. Re: SQLDA fix for ECPG

    Michael Meskes <meskes@postgresql.org> — 2011-11-17T13:53:42Z

    On Mon, Nov 14, 2011 at 09:06:30AM +0100, Boszormenyi Zoltan wrote:
    > Yes, you are right. For timestamp and interval, the safe alignment is int64.
    > Patch is attached.
    
    Applied, thanks.
    
    Michael
    -- 
    Michael Meskes
    Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
    Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
    Jabber: michael.meskes at googlemail dot com
    VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
    
    
  6. Re: SQLDA fix for ECPG

    Boszormenyi Zoltan <zb@cybertec.at> — 2011-11-19T21:56:03Z

    Hi,
    
    2011-11-17 14:53 keltezéssel, Michael Meskes írta:
    > On Mon, Nov 14, 2011 at 09:06:30AM +0100, Boszormenyi Zoltan wrote:
    >> Yes, you are right. For timestamp and interval, the safe alignment is int64.
    >> Patch is attached.
    > Applied, thanks.
    >
    > Michael
    
    thanks.
    
    Hopefully last turn in this topic. For NUMERIC types, the safe minimum
    alignment is a pointer because there are 5 int members followed by
    two pointer members in this struct. I got a crash from this with a lucky
    query and dataset. The DECIMAL struct is safe because the digits[] array
    is embedded there.
    
    After fixing this, I got another one at an innocent looking memcpy():
    
        memcpy((char *) sqlda + offset, num->buf, num->ndigits + 1);
    
    It turned out that when the server sends "0.00", PGTYPESnumeric_from_asc()
    constructs a numeric structure with:
        ndigits == 0
        buf == NULL
        digits == NULL.
    This makes memcpy() crash and burn. Let's also fix this case.
    
    Best regards,
    Zoltán Böszörményi
    
    -- 
    ----------------------------------
    Zoltán Böszörményi
    Cybertec Schönig & Schönig GmbH
    Gröhrmühlgasse 26
    A-2700 Wiener Neustadt, Austria
    Web: http://www.postgresql-support.de
         http://www.postgresql.at/
    
    
  7. Re: SQLDA fix for ECPG

    Michael Meskes <meskes@postgresql.org> — 2011-12-03T20:49:25Z

    On Sat, Nov 19, 2011 at 10:56:03PM +0100, Boszormenyi Zoltan wrote:
    > Hopefully last turn in this topic. For NUMERIC types, the safe minimum
    > alignment is a pointer because there are 5 int members followed by
    > two pointer members in this struct. I got a crash from this with a lucky
    > query and dataset. The DECIMAL struct is safe because the digits[] array
    > is embedded there.
    > ...
    
    Applied, thanks.
    
    Michael
    -- 
    Michael Meskes
    Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
    Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
    Jabber: michael.meskes at googlemail dot com
    VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL