On Monday, 17 June, 2019 21:36, Simon Slavin wrote:
>I understand about the RESERVED lock. I read the documentation. My
>surprise was at this, from further down the same page:
>" No EXCLUSIVE lock is acquired until either the memory cache fills
>up and must be spilled to disk or until the
You are preventing Group users from eXecuting your script by removing the
x. I think you wanted chmod 755 reading_room.tcl
Same for the db file where users of the same Group are not allowed to
Write.
Finally, I think locking may be a problem: users will run the script, which
will create journal
On 6/17/2019 11:35 PM, Simon Slavin wrote:
I suspect that a lot of software is using BEGIN when it should be using BEGIN
EXCLUSIVE.
A lot of software doesn't have persistent, long-lived reader transactions. If
your readers come in, get their data, and quickly get out, then a writer has
On 18 Jun 2019, at 4:19am, Keith Medcalf wrote:
> See https://sqlite.org/lockingv3.html
> for how transactions and locks work in journal_mode=delete|persist|truncate
> (ie, not WAL).
> There is a link on that page to how transactions work when WAL is in effect.
>
> Note that the default
On Monday, 17 June, 2019 18:46, Simon Slavin wrote:
>I think I see my error. I thought that the lock was promoted from
>read to read/write when the INSERT command was processed. At this
>point, SQLite knows that it is going to need to write.
>Instead, although SQLite knows that it is going
On Monday, 17 June, 2019 18:46, Simon Slavin wrote:
>I think I see my error. I thought that the lock was promoted from
>read to read/write when the INSERT command was processed. At this
>point, SQLite knows that it is going to need to write.
>Instead, although SQLite knows that it is going
Hi,
A connection doesn't need to check locks on every statement -
only when it tries to spill to disk, most commonly during
commit.
I think I understand what you wrote.
So the bit of my program can think that its changes were
written to the database and only later might my program find
E. Pasma,
Thank you, that gives me the results I was looking for, though I am still
working on fully understanding why, I have to totally refresh my memory on
the details of how the how nested set tree works, once I do, I am sure it
will be clear.
-
OT: about Pax vobiscum
I hope
I think I see my error. I thought that the lock was promoted from read to
read/write when the INSERT command was processed. At this point, SQLite knows
that it is going to need to write.
Instead, although SQLite knows that it is going to have to write, it does not
try to promote the lock
If you intend to update the database (ie, write to it) during a transaction,
you should begin that transaction with BEGIN IMMEDIATE; This signals that you
intend to WRITE to the database in that transaction and will prevent any other
connection from obtaining an INTENT (to write) lock.
BEGIN
On Monday, 17 June, 2019 17:50, Simon Slavin wrote:
>Can someone please explain this error message to me:
>
>Simple database, journal mode set to 'delete', accessed by two
>simultaneous sessions running the SQLite command-line shell,
>SQLite version 3.28.0 2019-04-15 14:49:49
>
>Session A:
>
On 6/17/2019 8:21 PM, Simon Slavin wrote:
On 18 Jun 2019, at 1:09am, Igor Tandetnik wrote:
A connection doesn't need to check locks on every statement - only when it
tries to spill to disk, most commonly during commit.
I think I understand what you wrote.
So the bit of my program can
On 18 Jun 2019, at 1:09am, Igor Tandetnik wrote:
> A connection doesn't need to check locks on every statement - only when it
> tries to spill to disk, most commonly during commit.
I think I understand what you wrote.
So the bit of my program can think that its changes were written to the
On 6/17/2019 7:49 PM, Simon Slavin wrote:
Is session B complaining that session A has a lock ?
Yes.
If session A had a lock why was there no complaint for the INSERT ?
A connection doesn't need to check locks on every statement - only when it
tries to spill to disk, most commonly during
Can someone please explain this error message to me:
Simple database, journal mode set to 'delete', accessed by two simultaneous
sessions running the SQLite command-line shell,
SQLite version 3.28.0 2019-04-15 14:49:49
Session A:
PRAGMA journal_mode; <-- says 'delete'
CREATE TABLE
Hello SQLite Users, fyi ...
26th Annual Tcl/Tk Conference (Tcl'2019)
https://www.tcl-lang.org/community/tcl2019/
November 04 - 08, 2019
Crowne Plaza Houston River Oaks
2712 Southwest Freeway, 77098
Houston, Texas, USA
[ NEWS
* Our keynote speaker is [Will
On 13/6/62 23:45, gwenn wrote:
Hello,
With the json1 extension, we can escape special characters like '['
from being interpreted as an array index by wrapping the path in
double quotes. But sometimes, it does not work:
Thanks for reporting this. Now fixed here:
On 17 Jun 2019, at 9:14am, Dominique Devienne wrote:
> SQLite4's LSM backend is now an extension in SQLite3 called LSM1
> https://www.sqlite.org/cgi/src/dir?ci=trunk=ext/lsm1=tree
>
> Which has been discussed in this list before.
> Few people are using it it seems, given the low volume of
On Sun, Jun 16, 2019 at 9:02 PM Simon Slavin wrote:
> On 16 Jun 2019, at 7:35pm, Amirouche Boubekki <
> amirouche.boube...@gmail.com> wrote:
>
> > Isn't this a use-case of LSM extension?
>
> It would seem a very good thing to do using LSM, but I can find
> documentation for LSM only in SQLite4,
19 matches
Mail list logo
