Hello, I just saw what could be a possible typo when acquiring a pending
lock.

In the current version of the amalgamation (3.7.10) line 23200 there is the
following code:

  /* Acquire a PENDING lock
  */
  if( locktype==EXCLUSIVE_LOCK && res == NO_ERROR ){
    newLocktype = PENDING_LOCK;
    gotPendingLock = 0;
    OSTRACE(( "LOCK %d acquire pending lock. pending lock boolean unset.\n",
               pFile->h ));
  }

In the surroundings of that snippet there are checks to acquire the
different kinds of locks but in all of them the lock type is tested against
what's is being acquired. Furthermore, the next test following this one to
acquire an exclusive lock has the same condition, which wouldn't
be necessary if the current code for the pending lock is correct:

/* Acquire an EXCLUSIVE lock
 */
 if( locktype==EXCLUSIVE_LOCK && res == NO_ERROR ){
   assert( pFile->locktype>=SHARED_LOCK );
   res = unlockReadLock(pFile);
...

In line 33996 the same situation happens:

 /* Acquire a PENDING lock
 */
 if( locktype==EXCLUSIVE_LOCK && res ){
   newLocktype = PENDING_LOCK;
   gotPendingLock = 0;
 }

It could be nothing, since I don't have a deep knowledge on how SQLite is
implemented, but in the documentation in
SQLite.org<http://sqlite.org/lockingv3.html>the following text
appears:

"A PENDING lock means that the process holding the lock wants to write to
the database as soon as possible and is just waiting on all current SHARED
locks to clear so that it can get an EXCLUSIVE lock."

Given the name of the variables involved in those pieces of code going from
an EXCLUSIVE lock to a PENDING lock doesn't seem logical. I've attached a
patch on how I think is correct in case it is preferable (available
here<http://pastebin.com/phEUEAiY>
 too).

Sorry for the trouble caused if the current state is correct.

Kind regards,
James Russell.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to