[sqlite] is the lemon parser error handling mechanism broken ?

[Jean-Francois Ostiguy]

Hello, 

since lemon is maintained as an integral part of sqlite, I am posting my report 
here.

* I  am using the latest available lemon.c and lempar.c [  20180421 and 
20180423 resp.]

The documentation  states:"The error recoverystrategy is to begin popping the 
parsers stack until it enters astate where it is permitted to shift a special 
non-terminal symbolnamed ``error''. It then shifts this non-terminal and 
continuesparsing. But the %syntax_error routine will not be called againuntil 
at least three new tokens have been successfully shifted.If the parser pops its 
stack until the stack is empty, and it stillis unable to shift the error 
symbol, then the %parse_failed routineis invoked and the parser resets itself 
to its start state, readyto begin parsing a new file. This is what will happen 
at the veryfirst syntax error, of course, if there are no instances of the 
``error'' non-terminal in your grammar."
This is definitely not what I observe.  Two cases need to be distinguished 

(1)  the non-terminal "error" symbol is not used in the grammar. 

  What happens: 
   -
  when a syntax error is encountered, the   %syntax_error   code is 
invoked. The parser then does 
  not attempt to shift the special error symbol. Rather, it discards the 
current token and proceeds with the next one. 
  For example, assuming a simple calculator grammar, 
  the input string   1+*1  triggers a syntax error when the "*" token is 
encountered. This '**" is rejected and 1+1 
  is   parsed. parse_fail is never invoked.

  Expected behavior
  -  1+*1  triggers a syntax error. Since the 
error symbol is not used in the grammar, the parser cannot shift the 
  error and as a result the parser ignores all subsequent tokens until the 
end of input is reached. parse_fail is invoked. 

(2) the non-terminal "error" symbol *is used* in the grammar. 
  Consider the following grammar, 
    
    
  
 
  statements   ::   statement.
  statements   ::   statements statement. 
   
      statement ::= error.  
  When a syntax error occurs , one would expect the  parser to call 
%syntax_error, shift the 
  error symbol and invoke the   "statement ::= error."  rule.  Subsequent 
tokens should then  
  get discarded until the parser can successfully perform 3 sequential 
shifts.   

       What actually happens:     
   The error symbol is shifted. The parser then crashes with the following 
error: 
   unsigned char yy_reduce(yyParser*, unsigned int, int, Token*): Assertion 
`yyruleno

Re: [sqlite] Stored Procedures

[Craig H Maynard]

Very useful comments in this thread. I recommend adding this to the SQLite FAQ, 
if it exists.

--
Craig H Maynard
Rhode Island, USA
401-413-2376


> Date: Tue, 8 May 2018 20:56:45 -0400
> From: Richard Hipp 
> To: SQLite mailing list 
> Subject: Re: [sqlite] Stored Procedures
> Message-ID:
>   

Re: [sqlite] This list is getting spammed again

[Simon Slavin]

On 9 May 2018, at 9:37pm, Cecil Westerhof  wrote:

> ​I am bitten by it also now. I posted a question and within two minutes I
> got a spam message​

I got three or four of these, each one soon after I'd posted a message.  Then I 
got no more.  I didn't do anything to stop them and I have checked my spam 
system to see if it stopped them, but the spam system didn't receive any more.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Only see unused when there are unused records

[Paul Sanderson]

Or

SELECT count(*) AS Total,
  CASE
WHEN Sum(used = 'unused') > 0 THEN Sum(used = 'unused')
  END AS NotUsed
FROM quotes

There might be a more succinct way


Paul
www.sandersonforensics.com
skype: r3scue193
twitter: @sandersonforens
Tel +44 (0)1326 572786
http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit
-Forensic Toolkit for SQLite
email from a work address for a fully functional demo licence

On 9 May 2018 at 21:31, Igor Tandetnik  wrote:

> On 5/9/2018 4:19 PM, Cecil Westerhof wrote:
>
>> I have a table where I use 'unused' to signify that a record is not yet
>> used. I want to know the number of unused records (but only if there are
>> unused records) and the total number of records.
>>
>
> Something like this perhaps:
>
> select count(*) Total, sum(totalUsed = 'unused') NotUsed from quotes;
>
> --
> Igor Tandetnik
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] This list is getting spammed again

[Cecil Westerhof]

2018-05-08 9:37 GMT+02:00 Domingo Alvarez Duarte :

> Again this list is getting spammed, I just received spam after publish.
>

​I am bitten by it also now. I posted a question and within two minutes I
got a spam message​

​that pretended to be a reply on my message.​

-- 
Cecil Westerhof
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Only see unused when there are unused records

[Igor Tandetnik]

On 5/9/2018 4:19 PM, Cecil Westerhof wrote:

I have a table where I use 'unused' to signify that a record is not yet
used. I want to know the number of unused records (but only if there are
unused records) and the total number of records.


Something like this perhaps:

select count(*) Total, sum(totalUsed = 'unused') NotUsed from quotes;

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Only see unused when there are unused records

[José María Mateos]

Sorry, re-reading your question I realized my solution doesn't work: it would 
return 0 when there are unused, but you don't want to see them.

Cheers,

-- 
José María (Chema) Mateos
https://rinzewind.org/blog-es || https://rinzewind.org/blog-en
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Only see unused when there are unused records

[José María Mateos]

On Wed, May 9, 2018, at 16:19, Cecil Westerhof wrote:
> I have a table where I use 'unused' to signify that a record is not yet
> used. I want to know the number of unused records (but only if there are
> unused records) and the total number of records.
> 
> At the moment I implemented it like:
> SELECT   *
> FROM (
> SELECT   'Not used'  AS Type
> ,COUNT(*)AS NoUsed
> FROM quotes
> WHEREtotalUsed == 'unused'
> UNION ALL
> SELECT   'Total'  AS Type
> ,COUNT(*) AS NoUsed
> FROM quotes
> )
> WHERENoUsed > 0
> 
> Is this correct, or is there a better way?

Would this work?

SELECT COUNT(*) AS Total,
  SUM(CASE WHEN totalUsed = 'unused' THEN 1 END) AS NotUsed
FROM quotes;

Cheers,

-- 
José María (Chema) Mateos
https://rinzewind.org/blog-es || https://rinzewind.org/blog-en
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Only see unused when there are unused records

[Cecil Westerhof]

I have a table where I use 'unused' to signify that a record is not yet
used. I want to know the number of unused records (but only if there are
unused records) and the total number of records.

At the moment I implemented it like:
SELECT   *
FROM (
SELECT   'Not used'  AS Type
,COUNT(*)AS NoUsed
FROM quotes
WHEREtotalUsed == 'unused'
UNION ALL
SELECT   'Total'  AS Type
,COUNT(*) AS NoUsed
FROM quotes
)
WHERENoUsed > 0

Is this correct, or is there a better way?

-- 
Cecil Westerhof
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "missing" sqlite3 invocation option?

[Simon Slavin]

On 9 May 2018, at 7:32pm, John McKown  wrote:

> The sqlite3 command has a input command to ".read" a file which "contains
> SQL in FILENAME". I am wondering why there isn't an equivalent command line
> argument to do this. That is, have something like:
> 
> sqlite3 -f FILENAME database.db3
> 
> which would do the same as:
> 
> sqlite3 database.db3
> sqlite> .read FILENAME
> sqlite> .quit

You can use the piping facilities of your command shell.  Depending on which OS 
and shell you're using, it might be something like

sqlite3 database.db3 < FILENAME

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] "missing" sqlite3 invocation option?

[John McKown]

The sqlite3 command has a input command to ".read" a file which "contains
SQL in FILENAME". I am wondering why there isn't an equivalent command line
argument to do this. That is, have something like:

sqlite3 -f FILENAME database.db3

which would do the same as:

sqlite3 database.db3
sqlite> .read FILENAME
sqlite> .quit

This would mirror the PostgreSQL supplied psql command. For whatever that
is worth.

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 3.24 draft - upsert

[Jim Callahan]

Per Keith Medcalf's comment on the ancient master file merge,
I found this inscription concerning batch processing in the elephant's
graveyard:

https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconc_batchscen2.htm

Jim Callahan

On Wed, May 9, 2018 at 10:06 AM, Keith Medcalf  wrote:

>
> This is a baby implementation of the master file merge from the early part
> of the last century (after the stone knives but somewhat before
> bearskins).
>
> Take two tables, one mounted on tape drive A, with output to tape drive B,
> updated from a transaction file on tape drive C.  Start Friday night.  Come
> Monday morning your master is now on drive B and up-to-date.
>
> --
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
> >-Original Message-
> >From: sqlite-users [mailto:sqlite-users-
> >boun...@mailinglists.sqlite.org] On Behalf Of Richard Hipp
> >Sent: Wednesday, 9 May, 2018 03:48
> >To: SQLite mailing list
> >Subject: Re: [sqlite] 3.24 draft - upsert
> >
> >On 5/9/18, Olivier Mascia  wrote:
> >> About:
> >>
> >> "Column names in the expressions of a DO UPDATE refer to the
> >original
> >> unchanged value of the column, before the attempted INSERT. To use
> >the value
> >> that would have been inserted had the constraint not failed, add
> >the special
> >> "excluded." table qualifier to the column name."
> >>
> >> Why using 'excluded' wording for this?
> >
> >Because that is what PostgreSQL does.  I also thought that "new"
> >would
> >have been a better choice, but they didn't consult me.  :-)
> >
> >--
> >D. Richard Hipp
> >d...@sqlite.org
> >___
> >sqlite-users mailing list
> >sqlite-users@mailinglists.sqlite.org
> >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 3.24 draft - upsert

[Keith Medcalf]

This is a baby implementation of the master file merge from the early part of 
the last century (after the stone knives but somewhat before bearskins).  

Take two tables, one mounted on tape drive A, with output to tape drive B, 
updated from a transaction file on tape drive C.  Start Friday night.  Come 
Monday morning your master is now on drive B and up-to-date.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Richard Hipp
>Sent: Wednesday, 9 May, 2018 03:48
>To: SQLite mailing list
>Subject: Re: [sqlite] 3.24 draft - upsert
>
>On 5/9/18, Olivier Mascia  wrote:
>> About:
>>
>> "Column names in the expressions of a DO UPDATE refer to the
>original
>> unchanged value of the column, before the attempted INSERT. To use
>the value
>> that would have been inserted had the constraint not failed, add
>the special
>> "excluded." table qualifier to the column name."
>>
>> Why using 'excluded' wording for this?
>
>Because that is what PostgreSQL does.  I also thought that "new"
>would
>have been a better choice, but they didn't consult me.  :-)
>
>--
>D. Richard Hipp
>d...@sqlite.org
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 3.24 draft - upsert

[Roman Fleysher]

Why does SQLite have to follow what PostgreSQL does? I thought SQLite is the 
leader.

Roman



Sent from my T-Mobile 4G LTE Device


 Original message 
From: Richard Hipp 
Date: 5/9/18 5:48 AM (GMT-05:00)
To: SQLite mailing list 
Subject: Re: [sqlite] 3.24 draft - upsert

On 5/9/18, Olivier Mascia  wrote:
> About:
>
> "Column names in the expressions of a DO UPDATE refer to the original
> unchanged value of the column, before the attempted INSERT. To use the value
> that would have been inserted had the constraint not failed, add the special
> "excluded." table qualifier to the column name."
>
> Why using 'excluded' wording for this?

Because that is what PostgreSQL does.  I also thought that "new" would
have been a better choice, but they didn't consult me.  :-)

--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Change location of "sqlite_history" with environment variable.

[Edênis Freindorfer Azevedo]

When using postgresql and mysql, you can use an environment variable to set
where their cli history should be saved (PSQL_HISTORY and MYSQL_HISTFILE).
These allow for partial XDG Base Directory Support.

Was there ever a discussion regarding using something similar for sqlite
(SQLITE_HISTFILE, for example)? I did a little bit of research, but I found
nothing. By looking at the code from the lastest snapshot, It feels like a
simple change (very basic testing, though).

I know this can be achieved by sym-linking "$HOME/.sql_history" to
somewhere else, but maybe this cause no troubles to code and could be a
feature request. What is the best way to ask for this?

[],
Edênis
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Lots of enhancements coming to version 3.24.0 - please test

[Seiji Amalai]

Nonono lol

On Tue, 8 May 2018, 15:42 Richard Hipp,  wrote:

> There are a lot of important changes in the SQLite code base since the
> previous release.  See
> https://www.sqlite.org/draft/releaselog/current.html for the latest
> summary.
>
> All of our legacy tests pass and many new test cases have been added.
> Nevertheless, your testing of SQLite in real-world applications is
> greatly appreciated.  Please consider downloading the latest
> pre-release snapshot (https://www.sqlite.org/download.html) and giving
> it a whirl.
>
> Report any problems or concerns to this mailing list, or directly to me.
>
> Thanks.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 3.24 draft - upsert

[Seiji Amalai]

Fuck you  suck

On Wed, 9 May 2018, 09:00 Olivier Mascia,  wrote:

> About:
>
> "Column names in the expressions of a DO UPDATE refer to the original
> unchanged value of the column, before the attempted INSERT. To use the
> value that would have been inserted had the constraint not failed, add the
> special "excluded." table qualifier to the column name."
>
> Why using 'excluded' wording for this?
> Couldn't 'new' be used as qualifier instead, akin to trigger syntax?
> Might be more coherent, and shorter for the parser.
>
> --
> Best Regards, Meilleures salutations, Met vriendelijke groeten,
> Olivier Mascia
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 3.24 draft - upsert

[Olivier Mascia]

> Le 9 mai 2018 à 11:48, Richard Hipp  a écrit :
> 
>> "Column names in the expressions of a DO UPDATE refer to the original
>> unchanged value of the column, before the attempted INSERT. To use the value
>> that would have been inserted had the constraint not failed, add the special
>> "excluded." table qualifier to the column name."
>> 
>> Why using 'excluded' wording for this?
> 
> Because that is what PostgreSQL does.  I also thought that "new" would
> have been a better choice, but they didn't consult me.  :-)

They should have.  :-)

Considering a simple case like this one, but with a possibly significant number 
of columns:

insert into T(K1,K2,C3,C4,...,CN) values (?1,?2,?3,?4,...?N)
  on conflict (K1,K2) do update set (C3,C4,...,CN) = (?3,?4,...,?N)

would this:

insert into T(K1,K2,C3,C4,...,CN) values (?1,?2,?3,?4,...?N)
  on conflict (K1,K2) do update set (C3,C4,...,CN) = 
(excluded.C3,excluded.C4,...,excluded.CN)

have a minor execution advantage or disadvantage over the first form?

If the first form, re-using parameters, is equally efficient (or better), I 
will have next to no use of the 'excluded' syntax from our C++ helper around 
SQLite API where we code such a simple upsert as:

st.upsert("T", { "K1", "K2" }, { "C3", "C4", ..., "CN" });  // prepare
st.run("ABC", "DEF", 10, 20.0, ..., "TEXT");// bind + exec
st.run("DEF", "GHI", 11, 18.0, ..., "OTHER");   // new bind + 
new exec

/* Pre 3.24 implementation used two hidden prepared statement behind (one 
update and one insert, running the insert only if the update said 'no 
changes'). */

-- 
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 3.24 draft - upsert

[R Smith]

On 2018/05/09 11:48 AM, Richard Hipp wrote:

On 5/9/18, Olivier Mascia  wrote:

About:

"Column names in the expressions of a DO UPDATE refer to the original
unchanged value of the column, before the attempted INSERT. To use the value
that would have been inserted had the constraint not failed, add the special
"excluded." table qualifier to the column name."

Why using 'excluded' wording for this?

Because that is what PostgreSQL does.  I also thought that "new" would
have been a better choice, but they didn't consult me.  :-)



It is probable they considered confusion with precisely the Trigger 
identifier we praise for its similarity.


On first read, "excluded" seemed unintuitive for me too, but the moment 
I started thinking in terms of "these are the rows that won't be 
included in the insert" (i.e. "The Excluded"), it quickly built a neural 
pathway in the noggin and now seems completely normal. Just needed a 
moment of acclimatization, as with any New thing. :)



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 3.24 draft - upsert

[Richard Hipp]

On 5/9/18, Olivier Mascia  wrote:
> About:
>
> "Column names in the expressions of a DO UPDATE refer to the original
> unchanged value of the column, before the attempted INSERT. To use the value
> that would have been inserted had the constraint not failed, add the special
> "excluded." table qualifier to the column name."
>
> Why using 'excluded' wording for this?

Because that is what PostgreSQL does.  I also thought that "new" would
have been a better choice, but they didn't consult me.  :-)

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Lots of enhancements coming to version 3.24.0 - please test

[Dominique Pellé]

Richard Hipp  wrote:

> There are a lot of important changes in the SQLite code base since the
> previous release.  See
> https://www.sqlite.org/draft/releaselog/current.html for the latest
> summary.

Some corrections in the draft doc:

In https://www.sqlite.org/draft/releaselog/current.html

"[...] EXPLAIN QUERY PLAN output *an* reformats it [...]"
-> typo: an -> and


In https://www.sqlite.org/draft/c3ref/keyword_check.html

"Put all *indentifier* names [...]"
-> typo: indentifier -> identifier


In https://www.sqlite.org/draft/eqp.html

"EXPLAIN QUERY PLAN is most useful on a SELECT statement, but may also *be*
appear with other statements that [...]"
-> The word "be" should be removed.

"In the *In the* following example [...]"
-> Repeated "In the"

"[...] is *acctually* evaluated [...]
-> typo: acctually -> actually

Regards
Dominique
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] 3.24 draft - upsert

[Olivier Mascia]

About:

"Column names in the expressions of a DO UPDATE refer to the original unchanged 
value of the column, before the attempted INSERT. To use the value that would 
have been inserted had the constraint not failed, add the special "excluded." 
table qualifier to the column name."

Why using 'excluded' wording for this?
Couldn't 'new' be used as qualifier instead, akin to trigger syntax?
Might be more coherent, and shorter for the parser.

-- 
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Does WAL mode's SQLITE_BUSY special circumstances invoke the busy handler?

[Clemens Ladisch]

Donald Shepherd wrote:
> The documentation on WAL databases includes a section with caveats re:
> SQLITE_BUSY, included below.  Do these invoke the busy handler (if
> configured) or just return SQLITE_BUSY immediately?

In general, SQLite calls the busy handler if there is a chance that
the lock will go away when waiting.

> Making a valiant attempt to read the code leads me to believe it
> returns immediately without involving the busy handler.

Search for "xBusy" or "xBusyHandler".

> - If another database connection has the database mode open in exclusive
> locking mode [...]
> - When the last connection to a particular database is closing, that
> connection will acquire an exclusive lock for a short time while it cleans
> up the WAL and shared-memory files. [...]
> - If the last connection to a database crashed, then the first new
> connection to open the database will start a recovery process. An exclusive
> lock is held during recovery.

These are not really 'special' circumstances, as far as locking algorithm
is concerned.  It's just that they happen less often when in WAL mode.

The second connection that tries to acquire the lock does not know the
reason for the existing exclusive lock.  In any case, waiting is the
right thing to do, so the busy handler is called.

The only case where the busy handler is avoided is in journal rollback
mode when neither connection has an exclusive lock yet (comment for
sqlite3BtreeBeginTrans()):

** If an initial attempt to acquire the lock fails because of lock contention
** and the database was previously unlocked, then invoke the busy handler
** if there is one.  But if there was previously a read-lock, do not
** invoke the busy handler - just return SQLITE_BUSY.  SQLITE_BUSY is
** returned when there is already a read-lock in order to avoid a deadlock.
**
** Suppose there are two processes A and B.  A has a read lock and B has
** a reserved lock.  B tries to promote to exclusive but is blocked because
** of A's read lock.  A tries to promote to reserved but is blocked by B.
** One or the other of the two processes must give way or there can be
** no progress.  By returning SQLITE_BUSY and not invoking the busy callback
** when A already has a read lock, we encourage A to give up and let B
** proceed.

(That case can be avoided by using BEGIN IMMEDIATE for transactions that
(might) write.)


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite3 fossil repository not working ?

[Jungle Boogie]

On Tue 08 May 2018  9:32 AM, Domingo Alvarez Duarte wrote:
> Hello !
> 
> Today I tried to update my sqlite3 repository but somehow it seems not
> working properly, I execute "fossil update" as usually and it contacts the
> server and exchange info with it but it only see till this commit
> http://www.sqlite.org/src/info/c381f0ea57002a264fd958b28e .
> 
> There is more than one fossil server and they are not synchronized ?

Have you tried the "fossil update trunk" command? This ensures you're on the
right branch. From a recent post, DRH advised the three repositories are synced
hourly to one another.

> 
> Cheers !
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users