Le 11/01/2022 à 18:58, Greg Troxel a écrit :
Jürgen E. Fischer <[email protected]> writes:
On Tue, 11. Jan 2022 at 09:10:57 -0500, [email protected] wrote:
I've tried making the gpkg read-only, which hasn't crashed anything in brief
testing and generates no warnings. However, it feels risky, and clearly QGIS
or OGR aren't fully happy, since the temporary shm and wal files don't get
deleted on exit. So I'm hesitant to continue doing this for fear of a crash
when I'm actually doing something useful.
We do the same with world_map.gpkg - see
https://github.com/qgis/QGIS/issues/35383.
I had seen that (NetBSD 9, pkgsrc, qgis 3.16.x) and wondered if it was a
packaging error I should look into. Now I understand. I have long
found it problematic that the wal/shm files exist and persist for long
periods, and that gpkd files I don't intend to change are modified at
the OS level.
It strikes me that the basic bug needs one of two things:
1) The geopackage driver should have a read-only access mode, and qgis
should start out that way, trying to change to read/write only when
the user hits the edit button on one of the layers. And, if the file
is read only, there should be a nice error like "can't make this layer
writable" and the toggle to write should fail.
The main issue I see is that it is unknown (and non documented AFAICS in
SQLite documentation) what happens if :
- reader A has opened the file with default journaling mode (for read-only)
- reader B (other QGIS process for example, or possibly the same QGIS
process like a renderer thread) has opened the file with default
journaling mode (for read-only)
- let's say A wants to edit and we thus enable WAL to avoid
reader/writer blocks
- is B which has opened without WAL still in a safe state ? Does it
react properly to WAL having been enabled behind its back ?
The default enabling of WAL even in initial read-only access mode is to
avoid that potential issue.
There are currently way of disabling WAL (for advanced users) :
- setting the OGR_SQLITE_JOURNALenvironment variable to JOURNAL
- or setting the QGIS setting "qgis/walForSqlite" to false
See
https://github.com/qgis/QGIS/blob/master/src/core/providers/ogr/qgsogrproviderutils.cpp#L1005
With this option, there perhaps needs to be some kind of lock outside
of sqlite, which can be multireader and single writer.
2) somehow, the geopackage layer could hide all this and logically open
the layer read/write, but refrain from writing to the filesystem.
Then, when there is an actual write, the db open-for-write can
happen. After the database is written, if no layers [are
editable]or[have unwrittend changes] for some period of time (5m?) the
database should be changed back to read only. This is sort of like 1
but at the gdal layer vs the qgis layer.
Because of this I'm starting to think about moving all my data into
postgis, and not use geopackages any more.
_______________________________________________
Qgis-user mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
Qgis-user mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
