[TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)

[Warren Young]

On 6/4/2013 03:37, Corinna Vinschen wrote:
>
> It would be nice to have a simple testcase (plain C, only Cygwin
> POSIX calls, self-contained, yada yada) to see what sqlite expects in
> POSIX lock mode.

SQLite locking is a hairball.  It is spread over a range of about 2.5 
kLOC within the 140 kLOC sqlite3.c file, and those routines are behind 
about three layers of indirection from the mainline SQLite code.

Mind, I'm not talking about the *callers* of this code here, just the 
locking routines themselves.  Add in all the callers and *their* 
expectations and...well...<shudder>

I think we have to define the problem as "SQLite locking requires what 
SQLite requires today."

Luckily, while creating the -2 packages, I stumbled across a STC in SQL 
that replicates the reported problem:

$ ./sqlite3 foo.db 'create table fred(id integer, barney text)'
$ CYGWIN_SQLITE_LOCKING=posixmand ./sqlite3 foo.db \
   'insert into fred(barney) values("wilma")'

If you change the locking mode to either "bsd" or "posix", it doesn't 
fail.  This gives hope that your new flock() implementation may work for us.

Here's hoping you can get the info you want from running the second 
command under strace.

I can tell you that it doesn't fail if you don't do a DB write.  For 
example, this succeeds regardless of locking strategy:

$ ./sqlite3 foo.db .q

You can see it open the DB file and turn on mandatory locking, but since 
it doesn't write to the DB file, it doesn't actually call flock().  The 
same goes for the other two locking strategies.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple