On 12 January 2016 at 13:12, Felipe Gasper wrote:
> Same code, just different processes.
>
> We?ve just noted over the years with race conditions that that ?if it can
> fail, it will?, so we try to be as bulletproof as we can.
>
Good policy :)
After you unlink the temp file, I presume the schem
On 12 January 2016 at 13:26, Scott Hess wrote:
> On Mon, Jan 11, 2016 at 9:12 PM, Felipe Gasper
> wrote:
>
> > On 11 Jan 2016 9:06 PM, Rowan Worth wrote:
> >
> >> * if it returns SQLITE_OK and zero rows, the schema hasn't been created
> >> yet
> >>
> >
> > Sure; however, by the time you do the n
On 12 January 2016 at 03:00, Felipe Gasper wrote:
> On 11 Jan 2016 1:45 PM, Scott Hess wrote:
>
>>
>> As far as preventing the other process from using it before the schema
>> exists, do "SELECT count(*) FROM sqlite_master", and if the result is 0,
>> the schema does not exist. If you create the
Please unsubscribe my id zia_khatri at yahoo.com
On Tuesday, January 12, 2016 11:19 AM, Rowan Worth
wrote:
On 12 January 2016 at 13:12, Felipe Gasper wrote:
> Same code, just different processes.
>
> We?ve just noted over the years with race conditions that that ?if it can
> fail, it w
On 11 Jan 2016 9:06 PM, Rowan Worth wrote:
> On 12 January 2016 at 03:00, Felipe Gasper wrote:
>
>> On 11 Jan 2016 1:45 PM, Scott Hess wrote:
>>
>>>
>>> As far as preventing the other process from using it before the schema
>>> exists, do "SELECT count(*) FROM sqlite_master", and if the result is
On 1/11/2016 11:52 PM, Scott Doctor wrote:
> TOCTTOU? What is that?
A friendly local search engine suggests it means "time of check to time
of use" ( https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use )
--
Igor Tandetnik
> On 12 January 2016 at 13:26, Scott Hess wrote:
>
> > On Mon, Jan 11, 2016 at 9:12 PM, Felipe Gasper
> > wrote:
> >
> > > On 11 Jan 2016 9:06 PM, Rowan Worth wrote:
> > >
> > >> * if it returns SQLITE_OK and zero rows, the schema hasn't been
> created
> > >> yet
> > >>
> > >
> > > Sure; howeve
On 2016/01/11 9:37 PM, Warren Young wrote:
> The OP was vague about that, but I think the point of his current
> gymnastics is to prevent the other process from creating a rogue
> schema, or to insert compromising data into a correct schema. To make
> it concrete, you could probably write a bl
So, if I understand correct, you create a file and then start to add a
schema etc. Before the schema is committed (or before the exclusive
transaction is started) you assume that other threads/processes /might/
be opening the file and trying to write some data to it (because reading
would be ha
On Mon, Jan 11, 2016 at 9:12 PM, Felipe Gasper
wrote:
> On 11 Jan 2016 9:06 PM, Rowan Worth wrote:
>
>> * if it returns SQLITE_OK and zero rows, the schema hasn't been created
>> yet
>>
>
> Sure; however, by the time you do the next action it?s possible that
> something else will be creating the
Felipe Gasper wrote:
> To prevent race conditions where a 2nd process accesses a newly-created
> SQLite file before the creator process can set up the schema, ...
And what happens when the 2nd process tries to access the database just
before the first creates it?
> I?m seeing some corruption in o
On 01/11/2016 18:06, Rowan Worth wrote:
> On 12 January 2016 at 03:00, Felipe Gasper wrote:
>
>> On 11 Jan 2016 1:45 PM, Scott Hess wrote:
>>
>>> As far as preventing the other process from using it before the schema
>>> exists, do "SELECT count(*) FROM sqlite_master", and if the result is 0,
>>
On Mon, Jan 11, 2016 at 7:57 PM, Stephan Beal wrote:
> On Mon, Jan 11, 2016 at 7:55 PM, Warren Young wrote:
>
>> On POSIX systems, you can securely create a temp file that only your user
>> can see via the mkstemp(3) C library call. SQLite will happily open the
>> resulting 0-byte file, allowin
On Mon, Jan 11, 2016 at 7:55 PM, Warren Young wrote:
> On POSIX systems, you can securely create a temp file that only your user
> can see via the mkstemp(3) C library call. SQLite will happily open the
> resulting 0-byte file, allowing you to create your schema inside it. Then
> when the file
On 11 Jan 2016, at 7:06pm, Warren Young wrote:
> On Jan 11, 2016, at 11:57 AM, Simon Slavin wrote:
>
>> Just do BEGIN IMMEDIATE immediately after you open the database.
>
> Doesn?t that set up a race condition? What prevents the other process from
> opening the DB and running its own SQL if
On 11 Jan 2016, at 6:25pm, Felipe Gasper wrote:
> - create SQLite file as a .tmp beside permanent location
I think you can omit everything to do with the link. Just do BEGIN IMMEDIATE
immediately after you open the database. This should lock other processes out
until you have finished creat
> What have folks here done to avoid the race condition originally described?
> I?ve seen some documentation of SQLite and hard links but
Your message appears to be truncated.
What if you move the hard link creation part to right after the commit?
On 11 Jan 2016 1:45 PM, Scott Hess wrote:
>
> As far as preventing the other process from using it before the schema
> exists, do "SELECT count(*) FROM sqlite_master", and if the result is 0,
> the schema does not exist. If you create the schema as a transaction, that
> will be atomic.
But in ord
On 11 Jan 2016 1:30 PM, Bernardo Sulzbach wrote:
>> What have folks here done to avoid the race condition originally described?
>> I?ve seen some documentation of SQLite and hard links but
>
> Your message appears to be truncated.
Oops! Nothing earth-shattering ? I meant to put ?but didn?t think
Hi all,
To prevent race conditions where a 2nd process accesses a newly-created
SQLite file before the creator process can set up the schema, I?ve
implemented logic like this:
- create SQLite file as a .tmp beside permanent location
- BEGIN EXCLUSIVE LOCK
- hard-link the temp file to
On Jan 11, 2016, at 12:27 PM, Simon Slavin wrote:
>
> On 11 Jan 2016, at 7:06pm, Warren Young wrote:
>
>> On Jan 11, 2016, at 11:57 AM, Simon Slavin wrote:
>>
>>> Just do BEGIN IMMEDIATE immediately after you open the database.
>>
>> Doesn?t that set up a race condition? What prevents the o
On Jan 11, 2016, at 11:57 AM, Simon Slavin wrote:
>
> Just do BEGIN IMMEDIATE immediately after you open the database.
Doesn?t that set up a race condition? What prevents the other process from
opening the DB and running its own SQL if the OS?s scheduler happens to take
the CPU away from the
On Mon, Jan 11, 2016 at 11:00 AM, Felipe Gasper
wrote:
> On 11 Jan 2016 1:45 PM, Scott Hess wrote:
>
>> As far as preventing the other process from using it before the schema
>> exists, do "SELECT count(*) FROM sqlite_master", and if the result is 0,
>> the schema does not exist. If you create t
On Jan 11, 2016, at 11:57 AM, Stephan Beal wrote:
>
> On Mon, Jan 11, 2016 at 7:55 PM, Warren Young wrote:
>
>> There must be an equivalent of mkstemp() on Windows, doubtless taking 3
>> times as many parameters and with a function name 4 times as long. :)
>
> sqlite exposes the functionality
On Jan 11, 2016, at 11:25 AM, Felipe Gasper wrote:
>
> To prevent race conditions where a 2nd process accesses a newly-created
> SQLite file before the creator process can set up the schema
On POSIX systems, you can securely create a temp file that only your user can
see via the mkstemp(
Since this doesn't provide a -journal file, certain kinds of crashes cannot
be recovered correctly.
Why you you hard-link before the commit? The schema doesn't exist until
the commit is successful, so there's no advantage to anyone else reading
the file before then.
As far as preventing the othe
26 matches
Mail list logo
