Postgis: Concurrency problem with CursorResultSet #1588

rcoup opened this Issue Nov 22, 2012 · 5 comments


None yet
3 participants

rcoup commented Nov 22, 2012


while trying to implement parallelism with asynchronous queries (#849), I ran into a curious thing in the Postgis plugin.

In the function features() implemented in postgis_datasource.cpp, the first thing done is to borrow a connection from the connection pool. Later, the method get_resultset is called with this connection, and if the datasource is supposed to use a cursor, it returns a CursorResultSet object, with the connection. Then the connection is given back to the pool, thanks to the PoolGuard.

The strange thing is that the CursorResultSet still uses the connection (in method getNextResultSet, called by next) after it has been given back. Am I right ?

Does somebody use postgis cursors in a concurrency context ? Has anybody ever had issues with that ?

Looks valid to me after a review


lexman commented Dec 3, 2012


we've started working on parallelization of datasource queries, which fixes this bug. It is not in the master and still needs some work to be merged, but you can have a look at our repo : , and comments about the code : Mappy#1


springmeyer commented Dec 3, 2012

excellent, thanks for the update!


springmeyer commented Mar 13, 2013

@rcoup - had a chance to work on this yet?

rcoup added a commit that referenced this issue May 6, 2013

Merge pull request #1823 from thjc/master
Fix for #1588 Postgis: Concurrency problem with CursorResultSet. Thanks @thjc

rcoup commented May 6, 2013

Fixed by #1823

@rcoup rcoup closed this May 6, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment