Re: ResultSet storing all rows with defaulftFetchSize to 5000

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: ResultSet storing all rows with defaulftFetchSize to 5000
Дата
Msg-id CAB=Je-GC4zSYuZ55s-TA4-Zuvw6k4gWNWfod1h2cT_iMMbPwBQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ResultSet storing all rows with defaulftFetchSize to 5000  (Jaime Soler <jaime.soler@gmail.com>)
Ответы Re: ResultSet storing all rows with defaulftFetchSize to 5000
Re: ResultSet storing all rows with defaulftFetchSize to 5000
Список pgsql-jdbc
Jaime>I am helping to migrate a Oracle application to run on Postgresql, and the default holdability setting at oracle is HOLD_CURSOR_OVER_COMMIT so I have tried to set this  HOLD_CURSOR_OVER_COMMIT as default holdability setting

Ok, that makes sense. I mean Oracle serves "fetch across commit" just fine (of course you can hit ORA-01555, but that is another story)

>-- after validating a chunk of data, continue with the next chunk 
>postgres=# commit;
>postgres=# fetch next p;

Wait. Did you just make up the output? Does PostgreSQL somehow supports "fetch across commit"?
What is your DB version?



I have no idea why PostgreSQL closes all the cursors as transaction ends, however that is the documented behavior.

42.7.3. Using Cursors -> All portals are implicitly closed at transaction end. Therefore a refcursor value is usable to reference an open cursor only until the end of the transaction.

pgjdbc just tries its best to avoid running into invalid (closed by backend) cursors, and pgjdbc fetches all the contents in HOLD_CURSOR_OVER_COMMIT case.

It might be something to be discussed on pgsql-hackers mailing list.
If only the DB did not close the portals...




Vladimir

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: ResultSet storing all rows with defaulftFetchSize to 5000
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ResultSet storing all rows with defaulftFetchSize to 5000