Re: cursor use vs pg_stat_statements
От | Andrew Dunstan |
---|---|
Тема | Re: cursor use vs pg_stat_statements |
Дата | |
Msg-id | 911483c7-f29a-d83b-875e-31d70d521bde@dunslane.net обсуждение исходный текст |
Ответ на | Re: cursor use vs pg_stat_statements (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: cursor use vs pg_stat_statements
|
Список | pgsql-hackers |
On 10/20/21 9:02 AM, Laurenz Albe wrote: > On Tue, 2021-10-19 at 15:24 -0400, Andrew Dunstan wrote: >> The problem I'm writing about (h/t Simon Riggs for finding it) is >> illustrated by the following snippet of java: >> >> public static void runtest(Connection conn) throws Exception { >> Statement stmt = conn.createStatement(); >> stmt.setFetchSize(10); >> ResultSet rs = stmt.executeQuery("select oid, relfileid, relname from pg_class"); >> int count = 100; >> while (rs.next() && count-- > 0) { >> System.out.print("."); >> } >> rs.close(); >> stmt.commit(); >> stmt.close(); >> System.out.println(""); >> } >> >> When called, this prints out a line with 100 dots showing 100 lines were >> fetched, but pg_stat_statements shows this: >> >> query | select oid, relfilenode, relname from pg_class >> calls | 1 >> rows | 10 >> >> >> suggesting only 10 rows were returned. It appears that only the first >> "EXECUTE 10" command against the portal is counted. At the very least >> this is a POLA violation, and it seems to be a bug. Maybe it's >> documented somewhere but if so it's not obvious to me. > I can't reproduce this on 14.1, after fixing the errors in your code: > > Try again with autocommit turned off. Sorry, I omitted that crucial detail. Exact test code attached (name/password removed) cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: