Thread: psqlODBC 09.05.0200 Released

psqlODBC 09.05.0200 Released

From
hiroshi@winpg.jp (Hiroshi Saito)
Date:
Hi, all.

We are release of psqlODBC 09.05.0200. this is a some bugfix release.
please see the notes at:

psqlODBC may be downloaded from in source, Windows Installer,
merge module, and basic zip file formats.

New Windows installer installs both 32-bit and 64-bit driver at once
on 64-bit OS. Both drivers may be needed on 64-bit OS because 32-bit
applications require 32-bit driver and 64-bit applications require
64-bit driver.

Please post any bug reports to the  mailing list.

I'd like to take this opportunity to thank all those involved with the
development, testing and bug fixing of the updated driver.

We are grateful to the help of many peoples. Thanks!

--
psqlODBC team.
email:   pgsql-odbc@postgresql.org
website: https://odbc.postgresql.org/


Re: psqlODBC 09.05.0200 Released

From
Adrian Klaver
Date:
On 04/09/2016 07:36 AM, Hiroshi Saito wrote:
> Hi, all.

Thanks.

>
> We are release of psqlODBC 09.05.0200. this is a some bugfix release.
> please see the notes at:

https://odbc.postgresql.org/docs/release.html

>
> psqlODBC may be downloaded from in source, Windows Installer,
> merge module, and basic zip file formats.
>
> New Windows installer installs both 32-bit and 64-bit driver at once
> on 64-bit OS. Both drivers may be needed on 64-bit OS because 32-bit
> applications require 32-bit driver and 64-bit applications require
> 64-bit driver.
>
> Please post any bug reports to the  mailing list.
>
> I'd like to take this opportunity to thank all those involved with the
> development, testing and bug fixing of the updated driver.
>
> We are grateful to the help of many peoples. Thanks!
>


--
Adrian Klaver
adrian.klaver@aklaver.com


Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
Hi, fyi, I keep getting...

+ cat ./regression.diffs
*** ./expected/param-conversions.out    Sat Apr  9 14:19:08 2016
--- results/param-conversions.out       Thu Apr 14 15:44:56 2016
***************
*** 72,83 ****

  Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
  SQLExecDirect failed
! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1";
  Error while executing the query

  Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
  SQLExecDirect failed
! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1";
  Error while executing the query

  Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
--- 72,83 ----

  Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
  SQLExecDirect failed
! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1";
  Error while executing the query

  Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
  SQLExecDirect failed
! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1";
  Error while executing the query

  Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
+ read line

... on Fedora 23.  I'll try to look more carefuly next week unless there
is somebody quicker than me.

Thanks, Pavel



Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Thursday 14 of April 2016 15:47:06 Pavel Raiskup wrote:
> Hi, fyi, I keep getting...
>
> + cat ./regression.diffs
> *** ./expected/param-conversions.out    Sat Apr  9 14:19:08 2016
> --- results/param-conversions.out       Thu Apr 14 15:44:56 2016
> ***************
> *** 72,83 ****
>
>   Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
>   SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1";
>   Error while executing the query
>
>   Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
>   SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1";
>   Error while executing the query
>
>   Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
> --- 72,83 ----
>
>   Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
>   SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1";
>   Error while executing the query
>
>   Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
>   SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1";
>   Error while executing the query
>
>   Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
> + read line
>
> ... on Fedora 23.  I'll try to look more carefuly next week unless there
> is somebody quicker than me.
>
> Thanks, Pavel

Full log:
https://kojipkgs.fedoraproject.org//work/tasks/9375/13659375/build.log

Pavel



Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
Weird, this should be reproducible almost everywhere, can somebody
confirm?

Seems like the attached patch should help, though it is a clear revert for
commit d5374bcc4d58556eb5cc70241c44dcad4d9b441e.  As there is no pointer
from the original fix to any discussion or bug report, I believe this is
regression and I'm proposing "as is".  Can you point me somewhere so we
can try to find a real fix for the original issue?

Thanks!
Pavel


On Thursday 14 of April 2016 15:48:16 Pavel Raiskup wrote:
> On Thursday 14 of April 2016 15:47:06 Pavel Raiskup wrote:
> > Hi, fyi, I keep getting...
> >
> > + cat ./regression.diffs
> > *** ./expected/param-conversions.out    Sat Apr  9 14:19:08 2016
> > --- results/param-conversions.out       Thu Apr 14 15:44:56 2016
> > ***************
> > *** 72,83 ****
> >
> >   Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
> >   SQLExecDirect failed
> > ! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1";
> >   Error while executing the query
> >
> >   Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
> >   SQLExecDirect failed
> > ! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1";
> >   Error while executing the query
> >
> >   Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
> > --- 72,83 ----
> >
> >   Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
> >   SQLExecDirect failed
> > ! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1";
> >   Error while executing the query
> >
> >   Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
> >   SQLExecDirect failed
> > ! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1";
> >   Error while executing the query
> >
> >   Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
> > + read line
> >
> > ... on Fedora 23.  I'll try to look more carefuly next week unless there
> > is somebody quicker than me.
> >
> > Thanks, Pavel
>
> Full log:
> https://kojipkgs.fedoraproject.org//work/tasks/9375/13659375/build.log
>
> Pavel

Attachment

Re: psqlODBC 09.05.0200 Released

From
"Inoue, Hiroshi"
Date:
Hi Pavel,

On 2016/04/18 22:02, Pavel Raiskup wrote:
> Weird, this should be reproducible almost everywhere, can somebody
> confirm?
>
> Seems like the attached patch should help, though it is a clear revert for
> commit d5374bcc4d58556eb5cc70241c44dcad4d9b441e.  As there is no pointer
> from the original fix to any discussion or bug report, I believe this is
> regression and I'm proposing "as is".  Can you point me somewhere so we
> can try to find a real fix for the original issue?

The commit handles the bug report
[ODBC] Issue with Money field using ODBC to Access database
   posted by John Van De Giessen on Febrary 14.
The bug was introduced in 9.5.0100 and the regression test result maybe
modified.

regards,
Hiroshi Inoue

>>> Hi, fyi, I keep getting...
>>>
>>> + cat ./regression.diffs
>>> *** ./expected/param-conversions.out    Sat Apr  9 14:19:08 2016
>>> --- results/param-conversions.out       Thu Apr 14 15:44:56 2016
>>> ***************
>>> *** 72,83 ****
>>>
>>>    Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
>>>    SQLExecDirect failed
>>> ! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1";
>>>    Error while executing the query
>>>
>>>    Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
>>>    SQLExecDirect failed
>>> ! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1";
>>>    Error while executing the query
>>>
>>>    Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
>>> --- 72,83 ----
>>>
>>>    Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
>>>    SQLExecDirect failed
>>> ! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1";
>>>    Error while executing the query
>>>
>>>    Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
>>>    SQLExecDirect failed
>>> ! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1";
>>>    Error while executing the query
>>>
>>>    Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
>>> + read line
>>>
>>> ... on Fedora 23.  I'll try to look more carefuly next week unless there
>>> is somebody quicker than me.
>>>
>>> Thanks, Pavel


Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
[dropping the announce list, sorry for not doing it before]

On Tuesday 19 of April 2016 07:50:30 Inoue, Hiroshi wrote:
> The commit handles the bug report
> [ODBC] Issue with Money field using ODBC to Access database
>    posted by John Van De Giessen on Febrary 14.

Thanks for the reference.  I have to look at the thread once more, as I
don't fully understand how that patch is relevant to MONEY type.

> The bug was introduced in 9.5.0100 and the regression test result maybe
> modified.

The test case shows that psqlodbc uses 'numeric' type for
SQL_FLOAT/SQL_DOUBLE id (instead of 'double precision' used before, or
'float8').  This sounds like a bug, or is this really expected?  If yes, I
can submit a patch fixing the test-case -- but it does not feel right.

Pavel



Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
Yet another testsuite issue, FYI:

+ cat ./regression.diffs
*** ./expected/declare-fetch-block.out    Fri Apr 15 13:11:35 2016
--- results/declare-fetch-block.out    Wed Apr 20 07:57:57 2016
***************
*** 2,10 ****
  fetchIdx=1, fetched rows=84, total rows=84
  fetchIdx=2, fetched rows=36, total rows=120
  next  total rows=120
! prior total rows=120
! next  total rows=120
! prior total rows=120
  FetchScroll beyond the end failed 100
! encountered EOF at 120
! disconnecting
--- 2,10 ----
  fetchIdx=1, fetched rows=84, total rows=84
  fetchIdx=2, fetched rows=36, total rows=120
  next  total rows=120
! prior total rows=20
! next  total rows=0
! prior total rows=0
  FetchScroll beyond the end failed 100
! FetchScroll the 1st row failed
! No error informatio

The architecture is armv7hl.

Pavel



Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Thursday 21 of April 2016 12:28:23 Pavel Raiskup wrote:
> Yet another testsuite issue, FYI:
>
> + cat ./regression.diffs
> *** ./expected/declare-fetch-block.out    Fri Apr 15 13:11:35 2016
> --- results/declare-fetch-block.out    Wed Apr 20 07:57:57 2016
> ***************
> *** 2,10 ****
>   fetchIdx=1, fetched rows=84, total rows=84
>   fetchIdx=2, fetched rows=36, total rows=120
>   next  total rows=120
> ! prior total rows=120
> ! next  total rows=120
> ! prior total rows=120
>   FetchScroll beyond the end failed 100
> ! encountered EOF at 120
> ! disconnecting
> --- 2,10 ----
>   fetchIdx=1, fetched rows=84, total rows=84
>   fetchIdx=2, fetched rows=36, total rows=120
>   next  total rows=120
> ! prior total rows=20
> ! next  total rows=0
> ! prior total rows=0
>   FetchScroll beyond the end failed 100
> ! FetchScroll the 1st row failed
> ! No error informatio
>
> The architecture is armv7hl.

I forgot to mention the full build log:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13729322

Pavel



Re: psqlODBC 09.05.0200 Released

From
Christoph Berg
Date:
Re: Pavel Raiskup 2016-04-14 <2358560.7dzo2vKd9I@nb.usersys.redhat.com>
> Hi, fyi, I keep getting...

Hi,

I'm getting exactly the same diff on Debian unstable.

Do we simply have to update expected/param-conversions{,_1}.out or is
there a bug in the (testing?) code?

> + cat ./regression.diffs
> *** ./expected/param-conversions.out    Sat Apr  9 14:19:08 2016
> --- results/param-conversions.out       Thu Apr 14 15:44:56 2016
> ***************
> *** 72,83 ****
>
>   Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
>   SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type double precision: "3', 'injected, BAD!', '1";
>   Error while executing the query
>
>   Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
>   SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type double precision: "4 \'bad', '1";
>   Error while executing the query
>
>   Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
> --- 72,83 ----
>
>   Testing "SELECT 1.3 > ?" with SQL_C_CHAR -> SQL_FLOAT param "3', 'injected, BAD!', '1"...
>   SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type numeric: "3', 'injected, BAD!', '1";
>   Error while executing the query
>
>   Testing "SELECT 1.4 > ?" with SQL_C_CHAR -> SQL_FLOAT param "4 \'bad', '1"...
>   SQLExecDirect failed
> ! 22P02=ERROR: invalid input syntax for type numeric: "4 \'bad', '1";
>   Error while executing the query
>
>   Testing "SELECT 1-?" with SQL_C_CHAR -> SQL_INTEGER param "-1"...
> + read line
>
> ... on Fedora 23.  I'll try to look more carefuly next week unless there
> is somebody quicker than me.

Christoph


Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Friday 22 of April 2016 12:19:28 Christoph Berg wrote:
> Re: Pavel Raiskup 2016-04-14 <2358560.7dzo2vKd9I@nb.usersys.redhat.com>
> > Hi, fyi, I keep getting...
>
> Hi,
>
> I'm getting exactly the same diff on Debian unstable.

It is not suprising, it is probably reproducible everywhere?

> Do we simply have to update expected/param-conversions{,_1}.out or is
> there a bug in the (testing?) code?

I suspect that is a bug in non-testing code, as SQL_FLOAT is now mapped to
'numeric' type, while it used to be mapped to 'double precission'.

Pavel



Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Thursday, April 21, 2016 12:32:16 PM CEST Pavel Raiskup wrote:
> On Thursday 21 of April 2016 12:28:23 Pavel Raiskup wrote:
> > Yet another testsuite issue, FYI:
> >
> > + cat ./regression.diffs
> > *** ./expected/declare-fetch-block.out    Fri Apr 15 13:11:35 2016
> > --- results/declare-fetch-block.out    Wed Apr 20 07:57:57 2016
> > ***************
> > *** 2,10 ****
> >   fetchIdx=1, fetched rows=84, total rows=84
> >   fetchIdx=2, fetched rows=36, total rows=120
> >   next  total rows=120
> > ! prior total rows=120
> > ! next  total rows=120
> > ! prior total rows=120
> >   FetchScroll beyond the end failed 100
> > ! encountered EOF at 120
> > ! disconnecting
> > --- 2,10 ----
> >   fetchIdx=1, fetched rows=84, total rows=84
> >   fetchIdx=2, fetched rows=36, total rows=120
> >   next  total rows=120
> > ! prior total rows=20
> > ! next  total rows=0
> > ! prior total rows=0
> >   FetchScroll beyond the end failed 100
> > ! FetchScroll the 1st row failed
> > ! No error informatio
> >
> > The architecture is armv7hl.
>
> I forgot to mention the full build log:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=13729322

I had to disable yet another test with 09.05.0300 on armv7hl, full build log
https://kojipkgs.fedoraproject.org//packages/postgresql-odbc/09.05.0300/1.fc25/data/logs/armv7hl/build.log

Pavel



Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Monday, June 20, 2016 6:45:51 AM CEST Pavel Raiskup wrote:
> On Thursday, April 21, 2016 12:32:16 PM CEST Pavel Raiskup wrote:
> > On Thursday 21 of April 2016 12:28:23 Pavel Raiskup wrote:
> > > Yet another testsuite issue, FYI:
> > >
> > > + cat ./regression.diffs
> > > *** ./expected/declare-fetch-block.out    Fri Apr 15 13:11:35 2016
> > > --- results/declare-fetch-block.out    Wed Apr 20 07:57:57 2016
> > > ***************
> > > *** 2,10 ****
> > >   fetchIdx=1, fetched rows=84, total rows=84
> > >   fetchIdx=2, fetched rows=36, total rows=120
> > >   next  total rows=120
> > > ! prior total rows=120
> > > ! next  total rows=120
> > > ! prior total rows=120
> > >   FetchScroll beyond the end failed 100
> > > ! encountered EOF at 120
> > > ! disconnecting
> > > --- 2,10 ----
> > >   fetchIdx=1, fetched rows=84, total rows=84
> > >   fetchIdx=2, fetched rows=36, total rows=120
> > >   next  total rows=120
> > > ! prior total rows=20
> > > ! next  total rows=0
> > > ! prior total rows=0
> > >   FetchScroll beyond the end failed 100
> > > ! FetchScroll the 1st row failed
> > > ! No error informatio
> > >
> > > The architecture is armv7hl.
> >
> > I forgot to mention the full build log:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=13729322
>
> I had to disable yet another test with 09.05.0300 on armv7hl, full build log
> https://kojipkgs.fedoraproject.org//packages/postgresql-odbc/09.05.0300/1.fc25/data/logs/armv7hl/build.log

The testsuite fails for s390x too, have a look at the results here:
http://s390.koji.fedoraproject.org/kojifiles/work/tasks/400/2270400/build.log

Pavel



Re: psqlODBC 09.05.0200 Released

From
"Tsunakawa, Takayuki"
Date:
> From: pgsql-odbc-owner@postgresql.org
> The testsuite fails for s390x too, have a look at the results here:
> http://s390.koji.fedoraproject.org/kojifiles/work/tasks/400/2270400/bu
> ild.log

Did any platform succeed (e.g. Intel64)?
Is there anything common among failed platforms (armv7hl, s390x), such as endian?

Regards
Takayuki Tsunakawa




Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote:
> Did any platform succeed (e.g. Intel64)?

No.  Looks like x86_64/i686 is in the best condition, we apply only one
downstream patch in Fedora (revert of the MONEY [1] fix which I believe should
be reverted upstream) and then the testsuite succeeds.

To build on armv7hl, we apply [2].

> Is there anything common among failed platforms (armv7hl, s390x), such as
> endian?

I haven't analyzed properly the common patterns yet.  FYI, there is also
downstream tracker [3] (seems like aarch64, s390* and ppc* fails too).

[1] http://pkgs.fedoraproject.org/cgit/rpms/postgresql-odbc.git/tree/postgresql-odbc-09.05.0210-revert-money-fix.patch
[2] http://pkgs.fedoraproject.org/cgit/rpms/postgresql-odbc.git/tree/postgresql-odbc-09.05.0210-tests-arm.patch
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1350486

Pavel



Re: psqlODBC 09.05.0200 Released

From
"Inoue, Hiroshi"
Date:
Hi Pavel,

On 2016/06/28 17:52, Pavel Raiskup wrote:
> On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote:
>> Did any platform succeed (e.g. Intel64)?
> No.  Looks like x86_64/i686 is in the best condition, we apply only one
> downstream patch in Fedora (revert of the MONEY [1] fix which I believe should
> be reverted upstream) and then the testsuite succeeds.
>
> To build on armv7hl, we apply [2].

Could you try the attached patch on armv7hl?

regards,
Hiroshi Inoue

Attachment

Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
Hi Hiroshi,

On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote:
> On 2016/06/28 17:52, Pavel Raiskup wrote:
> > On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote:
> >> Did any platform succeed (e.g. Intel64)?
> >
> > No.  Looks like x86_64/i686 is in the best condition, we apply only one
> > downstream patch in Fedora (revert of the MONEY [1] fix which I believe should
> > be reverted upstream) and then the testsuite succeeds.
> >
> > To build on armv7hl, we apply [2].
>
> Could you try the attached patch on armv7hl?

of course.  Submitted build (for i686, x86_64 and armv7hl):
http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892
.. and all arches passed testsuite, thanks!

There is just the remaining MONEY [1] revert patch.

Pavel



Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Sunday, July 24, 2016 10:09:18 AM CEST Pavel Raiskup wrote:
> Hi Hiroshi,
>
> On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote:
> > On 2016/06/28 17:52, Pavel Raiskup wrote:
> > > On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote:
> > >> Did any platform succeed (e.g. Intel64)?
> > >
> > > No.  Looks like x86_64/i686 is in the best condition, we apply only one
> > > downstream patch in Fedora (revert of the MONEY [1] fix which I believe should
> > > be reverted upstream) and then the testsuite succeeds.
> > >
> > > To build on armv7hl, we apply [2].
> >
> > Could you try the attached patch on armv7hl?
>
> of course.  Submitted build (for i686, x86_64 and armv7hl):
> http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892
> .. and all arches passed testsuite, thanks!
>
> There is just the remaining MONEY [1] revert patch.

FYI:

aarch64 passes too:
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3639510

s390 still fails:
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2297311

Pavel



Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Sunday, July 24, 2016 10:19:42 AM CEST Pavel Raiskup wrote:
> On Sunday, July 24, 2016 10:09:18 AM CEST Pavel Raiskup wrote:
> > Hi Hiroshi,
> >
> > On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote:
> > > On 2016/06/28 17:52, Pavel Raiskup wrote:
> > > > On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote:
> > > >> Did any platform succeed (e.g. Intel64)?
> > > >
> > > > No.  Looks like x86_64/i686 is in the best condition, we apply only one
> > > > downstream patch in Fedora (revert of the MONEY [1] fix which I believe should
> > > > be reverted upstream) and then the testsuite succeeds.
> > > >
> > > > To build on armv7hl, we apply [2].
> > >
> > > Could you try the attached patch on armv7hl?
> >
> > of course.  Submitted build (for i686, x86_64 and armv7hl):
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892
> > .. and all arches passed testsuite, thanks!
> >
> > There is just the remaining MONEY [1] revert patch.
>
> FYI:
>
> aarch64 passes too:
> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3639510
>
> s390 still fails:
> http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2297311

ppc64 fails, ppc64le (little endian) succeeds.
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3549998

Looks like remaining failure is big-endian related?

Pavel



Re: psqlODBC 09.05.0200 Released

From
"Inoue, Hiroshi"
Date:
On 2016/07/24 18:28, Pavel Raiskup wrote:
> On Sunday, July 24, 2016 10:19:42 AM CEST Pavel Raiskup wrote:
>> On Sunday, July 24, 2016 10:09:18 AM CEST Pavel Raiskup wrote:
>>> Hi Hiroshi,
>>>
>>> On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote:
>>>> On 2016/06/28 17:52, Pavel Raiskup wrote:
>>>>> On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote:
>>>>>> Did any platform succeed (e.g. Intel64)?
>>>>> No.  Looks like x86_64/i686 is in the best condition, we apply only one
>>>>> downstream patch in Fedora (revert of the MONEY [1] fix which I believe should
>>>>> be reverted upstream) and then the testsuite succeeds.
>>>>>
>>>>> To build on armv7hl, we apply [2].
>>>> Could you try the attached patch on armv7hl?
>>> of course.  Submitted build (for i686, x86_64 and armv7hl):
>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892
>>> .. and all arches passed testsuite, thanks!
>>>
>>> There is just the remaining MONEY [1] revert patch.
>> FYI:
>>
>> aarch64 passes too:
>> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3639510
>>
>> s390 still fails:
>> http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2297311
> ppc64 fails, ppc64le (little endian) succeeds.
> http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3549998
>
> Looks like remaining failure is big-endian related?

Possibly the attached patch fixes the failure.

regards,
Hiroshi Inoue

Attachment

Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Sunday, July 24, 2016 7:05:46 PM CEST Inoue, Hiroshi wrote:
>
> On 2016/07/24 18:28, Pavel Raiskup wrote:
> > On Sunday, July 24, 2016 10:19:42 AM CEST Pavel Raiskup wrote:
> >> On Sunday, July 24, 2016 10:09:18 AM CEST Pavel Raiskup wrote:
> >>> Hi Hiroshi,
> >>>
> >>> On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote:
> >>>> On 2016/06/28 17:52, Pavel Raiskup wrote:
> >>>>> On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote:
> >>>>>> Did any platform succeed (e.g. Intel64)?
> >>>>> No.  Looks like x86_64/i686 is in the best condition, we apply only one
> >>>>> downstream patch in Fedora (revert of the MONEY [1] fix which I believe should
> >>>>> be reverted upstream) and then the testsuite succeeds.
> >>>>>
> >>>>> To build on armv7hl, we apply [2].
> >>>> Could you try the attached patch on armv7hl?
> >>> of course.  Submitted build (for i686, x86_64 and armv7hl):
> >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892
> >>> .. and all arches passed testsuite, thanks!
> >>>
> >>> There is just the remaining MONEY [1] revert patch.
> >> FYI:
> >>
> >> aarch64 passes too:
> >> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3639510
> >>
> >> s390 still fails:
> >> http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2297311
> > ppc64 fails, ppc64le (little endian) succeeds.
> > http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3549998
> >
> > Looks like remaining failure is big-endian related?
>
> Possibly the attached patch fixes the failure.

Right.  Ater that the testsuite is OK on Fedora architectures where I'm able to
test (still need to revert MONEY fix [1]).

Can you please push the fixes into repository?

Thanks,
Pavel



Re: psqlODBC 09.05.0200 Released

From
"Inoue, Hiroshi"
Date:

On 2016/07/24 17:09, Pavel Raiskup wrote:
> Hi Hiroshi,
>
> On Sunday, July 24, 2016 12:19:01 PM CEST Inoue, Hiroshi wrote:
>> On 2016/06/28 17:52, Pavel Raiskup wrote:
>>> On Tuesday, June 28, 2016 5:36:43 AM CEST Tsunakawa, Takayuki wrote:
>>>> Did any platform succeed (e.g. Intel64)?
>>> No.  Looks like x86_64/i686 is in the best condition, we apply only one
>>> downstream patch in Fedora (revert of the MONEY [1] fix which I believe should
>>> be reverted upstream) and then the testsuite succeeds.
>>>
>>> To build on armv7hl, we apply [2].
>> Could you try the attached patch on armv7hl?
> of course.  Submitted build (for i686, x86_64 and armv7hl):
> http://koji.fedoraproject.org/koji/taskinfo?taskID=15001892
> .. and all arches passed testsuite, thanks!
>
> There is just the remaining MONEY [1] revert patch.

It's difficult to revert the commit because the functionality exists
before 9.5.
I'm inclined to omit 2 cases in trouble from param-conversions-test for
the time being.
Is it OK?

regards,
Hiroshi Inoue


Re: psqlODBC 09.05.0200 Released

From
Pavel Raiskup
Date:
On Monday, July 25, 2016 7:12:11 AM CEST Inoue, Hiroshi wrote:
> It's difficult to revert the commit because the functionality exists
> before 9.5.
> I'm inclined to omit 2 cases in trouble from param-conversions-test for
> the time being.
> Is it OK?

As I understand the problem, the regression test caught real issue ...
i.e. there is (a) bug fixed but (b) new regression added.

I'm not able to measure what issue is more serious, but the fixed bug 'a'
is looks like related to very small subset of users, while 'b' is related to
everybody ...

... so (when the revert is no-go) rather than removing the tests completely,
I would suggest you to mark them as "expected failure" and wait for the fix in
future.  I'm fine to keep that patch reverted downstream for the time being.

I'm glad have fixes for the portability issues, I can't wait for having it
committed!

Pavel



Re: psqlODBC 09.05.0200 Released

From
"Inoue, Hiroshi"
Date:

On 2016/07/25 16:34, Pavel Raiskup wrote:
> On Monday, July 25, 2016 7:12:11 AM CEST Inoue, Hiroshi wrote:
>> It's difficult to revert the commit because the functionality exists
>> before 9.5.
>> I'm inclined to omit 2 cases in trouble from param-conversions-test for
>> the time being.
>> Is it OK?
> As I understand the problem, the regression test caught real issue ...
> i.e. there is (a) bug fixed but (b) new regression added.
>
> I'm not able to measure what issue is more serious, but the fixed bug 'a'
> is looks like related to very small subset of users, while 'b' is related to
> everybody ...
>
> ... so (when the revert is no-go) rather than removing the tests completely,
> I would suggest you to mark them as "expected failure" and wait for the fix in
> future.  I'm fine to keep that patch reverted downstream for the time being.
>
> I'm glad have fixes for the portability issues, I can't wait for having it
> committed!

I changed expected/param-converions(_1).out as-is and pushd to git.
Now all regression tests passes.

regards,
Hiroshi Inoue