Re: BUG on postgresql-9.4-1201-jdbc41 ...

From: Alexis Meneses <alexis(dot)meneses(at)gmail(dot)com>
To: Yoann Gendre <ygendre(at)dsirc(dot)net>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: BUG on postgresql-9.4-1201-jdbc41 ...
Date: 2015-05-11 21:05:52
Message-ID: CANPkoZTLo2wyYasouADGdUMLd1hUdJv_wXLSq84ZOjzo98Zr2g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Yoann,

I must have missed the github notification for the PR you opened on my
branch.

Anyway, thanks for the update, we now have a failing case on which we can
work on (to anyone else interrested in, the commit is located at following
location:
https://github.com/yge45/pgjdbc/commit/69df4e0c210202246dd503a51f51dabe3cc7153b
).

I'll have a closer look at it ASAP, but it may not be before the end of the
week.

Alexis Meneses

2015-05-11 15:17 GMT+02:00 Yoann Gendre <ygendre(at)dsirc(dot)net>:

> Hi alexis,
>
> Few days ago I pull a request to improve the junit test. Did you have a
> look at it ?
>
>
> Thanks.
>
> Yoann GENDRE
> DSI-RC / Cadrage Stratégique
> Pôle Architecture et Urbanisme
> Tél : 06 27 47 20 41 / 01.71.72.16.30
>
> 2015-04-02 20:41 GMT+02:00 Alexis Meneses <alexis(dot)meneses(at)gmail(dot)com>:
>
>> Hi,
>>
>> I've tried to transpose the test case you mention in the junit test suite
>> (see commit 2a4d01ec6d
>> <https://github.com/alexismeneses/pgjdbc/commit/2a4d01ec6d8cb818f1b16f1b179d7d1570877ae8>)
>> but I do not manage to make it fail (see related build job
>> <https://travis-ci.org/alexismeneses/pgjdbc/jobs/56923708> on JDK7 /
>> PostgreSQL v9.3
>> <https://travis-ci.org/alexismeneses/pgjdbc/jobs/56923708> which turns
>> out to be successful).
>>
>> Would you have enough time to fork and improve the junit test so as to
>> highlight the bug you're suspecting?
>>
>> Thanks.
>>
>> Alexis Meneses
>>
>>
>> 2015-04-02 14:57 GMT+02:00 <lpintodacosta(at)girc(dot)agirc-arrco(dot)fr>:
>>
>>> Hello,
>>>
>>> I've got an issue with fetching behavior and ResultSet.isAfterLast
>>> method. I think it comes from the fact that isAfterLast is checked on
>>> current fetched page and not checked for the whole resulset.
>>>
>>>
>>> To illustrate my problem here is a test case - tested :
>>> - JDBC driver build number : postgresql-9.4-1201-jdbc41.jar
>>>
>>> - - JVM : 1.7
>>> - - PostgreSQL version : 9.3.5
>>>
>>>
>>> - structure & data
>>> CREATE TABLE test_table(col1 numeric(19,0) NOT NULL);
>>> INSERT INTO test_table(col1) VALUES (1);
>>> INSERT INTO test_table(col1) VALUES (2);
>>> INSERT INTO test_table(col1) VALUES (3);
>>> INSERT INTO test_table(col1) VALUES (4);
>>>
>>> - java code
>>> final String databaseUrl =
>>> "jdbc:postgresql://localhost:5432/RNA?loglevel=2";
>>> final Properties properties = new Properties();
>>> properties.setProperty("user", "postgres");
>>> properties.setProperty("password", "pwd");
>>> connection = DriverManager.getConnection(databaseUrl, properties);
>>> connection.setAutoCommit(false);
>>> Statement statement = connection.createStatement(
>>> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
>>>
>>> statement.setFetchSize(fetchSize);
>>>
>>> ResultSet result = statement
>>> .executeQuery("select * from TEST_TABLE");
>>>
>>> while (result.next()) {
>>> System.out.println("row " + result.getString(1)
>>> + " - result.isAfterLast()=" + result.isAfterLast());
>>> }
>>> System.out
>>> .println("after there is no more row - result.isAfterLast()="
>>> + result.isAfterLast());
>>>
>>> result.close();
>>> statement.close();
>>>
>>> - results
>>> if fetchSize = 3, I can see in output :
>>>
>>> 12:16:02.005 (2) FE=> Parse(stmt=S_1,query="select * from
>>> TEST_TABLE",oids={})
>>> 12:16:02.005 (2) FE=> Execute(portal=C_2,limit=3)
>>> row 1 - result.isAfterLast()=false
>>> row 2 - result.isAfterLast()=false
>>> row 3 - result.isAfterLast()=false
>>> 12:16:02.007 (2) FE=> Execute(portal=C_2,limit=3)
>>> row 4 - result.isAfterLast()=false
>>> after there is no more row - result.isAfterLast()=true ====> seems
>>> OK - I've navigate through the 4 rows
>>>
>>>
>>> but if fetchSize = 2, I can see in output :
>>> 12:16:01.963 (1) FE=> Parse(stmt=S_1,query="select * from
>>> TEST_TABLE",oids={})
>>> 12:16:01.963 (1) FE=> Execute(portal=C_2,limit=2)
>>> row 1 - result.isAfterLast()=false
>>> row 2 - result.isAfterLast()=false
>>> 12:16:01.976 (1) FE=> Execute(portal=C_2,limit=2)
>>> row 3 - result.isAfterLast()=false
>>> row 4 - result.isAfterLast()=false
>>> 12:16:01.976 (1) FE=> Execute(portal=C_2,limit=2)
>>> 12:16:01.977 (1) <=BE CommandStatus(SELECT 0)
>>> after there is no more row - result.isAfterLast()=false ====> KO -
>>> I've navigate through the 4 rows and afterLast is still false.
>>>
>>>
>>>
>>> Cordialement.
>>>
>>> *Luis Michel PINTO DA COSTA*
>>> * GIRC Agirc-Arrco*
>>> *A*rchitecture et *I*nfrastructure *L*ogicielle - *I*nfrastructure
>>> *M*iddleware & *S*GBD - Ormes
>>> Tél : 02 38 42 83 15
>>> lpintodacosta(at)girc(dot)agirc-arrco(dot)fr
>>>
>>>
>>
>

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Jeremy Whiting 2015-05-13 08:01:46 Re: Resource lookup timeout causes Travis IC to fail test.
Previous Message Dave Cramer 2015-05-10 00:24:44 Re: Regarding inclusion of indexes as tables