[GRASS-user] SQLITE db locking problem - update

[Mark Wynter]

Still no luck solving SQLite db locking issue.

I’ve opted for PG db instead - a nicer solution insofar PG is where the data comes from and goes to in my analytics pipeline.  There’s also an efficiency dividend, thanks to  the v.out.postgis -t flag - which exports the grass geometries and cat values, but not the attribute table - which is much faster than v.out.ogr, as the grass attribute data is already in PG.  I then use psql to do a join in PostGIS on the geom and attribute cat values to build the final table for subsequent analysis in PostGIS.   :-))  

v.out.postgis -t  is a great feature - thanks Martin Landa!!!

----------------------------------------------------------------------

Message: 1
Date: Mon, 19 Jan 2015 00:53:58 +1030
From: Mark Wynter <mark at dimensionaledge.com>
To: grass <grass-user at lists.osgeo.org>
Subject: [GRASS-user] SQLITE db locking problem
Message-ID: <6BD86E4F-3B17-42D1-ACC3-25E3A3C29C3C at dimensionaledge.com>
Content-Type: text/plain; charset="windows-1252"

Hi everyone

I?m having issues with SQLITE as the db driver - I encounter this BUSY warning.  Only occurs when patching a particular map, in this case  ?temp_nbt_cleaned" which is the largest of the datasets being patched.  If I work with smaller datasets, it works fine.  Pre-patching, SQLITE DB size is only 170MB.

I?ve come across various threads reporting something similar with db locking.  But couldn?t find a resolution.
I?m running grass70 on Centos65, hosted on AWS..  SQLite is version 3.6.23.1 

This is the error message.

GRASS 7.0.0svn (nodeclean):/var/tmp > v.patch -e input=temp_t_cleaned,temp_b_cleaned,temp_nbt_cleaned out=temp_patched
Patching vector map <temp_t_cleaned>...
Patching vector map <temp_b_cleaned>...
Patching vector map <temp_nbt_cleaned>...
WARNING: Busy SQLITE db, already waiting for 10 seconds?
WARNING: Busy SQLITE db, already waiting for 20 seconds?
etc
etc

I encounter no problems patching the maps, including ?temp_nbt_cleaned" if I use PG db driver, or DBF driver.


I?m more than comfortable using PG in the backend, but I find v.out.postgis too slow when exporting the resultant dataset back to postgis (possibly because its simultaneously trying to read and write to the same db). I haven?t tested whether v.out.ogr quicker than v.out.postgis.