Sandy Ganz wrote:
This doesn't sound right, I have seen the problem that linux will not use
the allocated memory until it is touched, but doesn't the memory manger keep
track ultimatly of all allocations (in the kernel which as all encompassing
knowledge of allocations) which might include things
On Dec 31, 2004, at 9:11 AM, Thomas Fjellstrom wrote:
On December 31, 2004 06:37 am, D. Richard Hipp wrote:
Even in version 3.0.8, if you have a query running on a table
that has not yet returned SQLITE_DONE, then you are prohibited
from making changes to that table.
So something as simple as:
This doesn't sound right, I have seen the problem that linux will not use
the allocated memory until it is touched, but doesn't the memory manger keep
track ultimatly of all allocations (in the kernel which as all encompassing
knowledge of allocations) which might include things that have not yet
On 1/4/2005 at 12:13 Sandy Ganz wrote:
>What OS does not return NULL or an exception when malloc() fails or is
out
>of memory?
OS/2. Linux kernels < 2.6. I think Windows does this too, but I'm
not sure.
Its harder than you might think to implement, because most OSes don't
allocate memory
One poster mentioned some OS's will not let you know when you're
out of RAM (malloc() never fails). That might be difficult!
--- Darren Duncan <[EMAIL PROTECTED]> wrote:
> If possible, SQLite should also manage memory so that it has the
> resources necessary to roll back the infinite recursion
Regarding the risk of infinite loops with triggers ...
I believe that SQLite's default case should be to simply let
resources define the limits, and stop only when there simply aren't
the resources to continue.
As with most programming languages, it should be the user's
responsibility to not
samba filesystem does not support that style of locking API on Mac OS X.
Is there any known workarounds to get it to work correctly?
A time machine :-)
The SMB protocol does Windows style locking which has various
wierd and wonderful semantics. But they have nothing in common
with UNIX locking
[EMAIL PROTECTED] wrote:
On Tue, 4 Jan 2005, Steve Milner wrote:
Hello List,
I am having a problem with SQLite erroring out on Mac OS X. I am
using 3.0.8. The problem happens when it tries to access a
SAMBA/CIFS shared database. In my testing Windows to Linux and
Linux to Windows worked
On Tue, 4 Jan 2005, Steve Milner wrote:
Hello List,
I am having a problem with SQLite erroring out on Mac OS X. I am
using 3.0.8. The problem happens when it tries to access a SAMBA/CIFS
shared database. In my testing Windows to Linux and Linux to Windows
worked fine, but Mac to Windows
Ara.T.Howard wrote:
On Tue, 4 Jan 2005, Steve Milner wrote:
Hello List,
I am having a problem with SQLite erroring out on Mac OS X. I am
using 3.0.8. The problem happens when it tries to access a SAMBA/CIFS
shared database. In my testing Windows to Linux and Linux to Windows
worked fine, but
On Tue, Jan 04, 2005 at 05:54:04AM -0500, D. Richard Hipp wrote:
> One stubling block with recursive triggers is that a recursive
> trigger can result in an infinite loop. I sent out a query a
> month or so ago requesting ideas on how to detect and deal with
> infinite loops in recursive
On 1/4/2005 at 15:54 Paolo Vernazza wrote:
>>It seems to me that recursion that never touches the same row twice
is
>>less an issue. That is a trigger that just updates all other rows in
>>the table once should be fine. So one (I suspect hard to implement)
>>idea would be to keep track of
On Jan 4, 2005, at 7:03 AM, Brass Tilde wrote:
FWIW, I'm told by our DBA that SQL Server 2000 has a setting that
allows or
disallows recursive trigger execution. When disallowed, triggers
apparently
just don't recursively call themselves, even if they are designed to
do so,
i.e. they won't
> CREATE TRIGGER deep BEFORE DELETE ON list BEGIN
> DELETE FROM list WHERE id=old.next;
> END;
>
> This trigger is guaranteed to terminate because it will
> eventually run out of entries to delete. But given any
> recursion limit, we can always construct a case where
> the trigger
Henry Miller wrote:
It seems to me that recursion that never touches the same row twice is
less an issue. That is a trigger that just updates all other rows in
the table once should be fine. So one (I suspect hard to implement)
idea would be to keep track of which rows have been touched as part
--- "D. Richard Hipp" <[EMAIL PROTECTED]> wrote:
> Peter Bartholdsson wrote:
> > Think the topic explains it but there any way to enable recursive
> triggers?
> > Aka, triggers that run as result of a change by a trigger.
> >
>
> Recursive triggers are on the todo list. They are a
On 1/4/2005 at 08:48 D. Richard Hipp wrote:
>Peter Bartholdsson wrote:
>>
>> [H]ow would [limiting recursion depth] not be enough?
>>
>
>Limiting the recursion depth would be sufficient to prevent
>infinite loops. But it seems overly restrictive.
>
>Consider the following case:
>
>CREATE
> So do we put recursion limits on UPDATE and INSERT triggers
> only and let DELETE triggers run as long as they like?
> That works as far as I know, but it seems kind of arbitrary.
>
> Surely somebody else has been down this road before me and
> can offer a little guidance?
Why don't give this
Hello List,
I am having a problem with SQLite erroring out on Mac OS X. I am using
3.0.8. The problem happens when it tries to access a SAMBA/CIFS shared
database. In my testing Windows to Linux and Linux to Windows worked
fine, but Mac to Windows fails with the following:
Traceback (most
Peter Bartholdsson wrote:
[H]ow would [limiting recursion depth] not be enough?
Limiting the recursion depth would be sufficient to prevent
infinite loops. But it seems overly restrictive.
Consider the following case:
CREATE TABLE list(
id INTEGER PRIMARY KEY,
next INTEGER REFERENCES
On Tue, 04 Jan 2005 05:54:04 -0500, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
Peter Bartholdsson wrote:
Think the topic explains it but there any way to enable recursive triggers?
Aka, triggers that run as result of a change by a trigger.
Recursive triggers are on the todo list. They are a
I think that a good and simple solution is simply
limit the level of recursivity. Maybe 16 nested
recursive calls solve 95% of the recursive needs.
Cláudio
> Peter Bartholdsson wrote:
> > Think the topic explains it but there any way to
> enable recursive triggers?
> > Aka, triggers that run as
Peter Bartholdsson wrote:
Think the topic explains it but there any way to enable recursive triggers?
Aka, triggers that run as result of a change by a trigger.
Recursive triggers are on the todo list. They are a prerequisite
for the planned implementation of foreign keys.
One stubling block with
Think the topic explains it but there any way to enable recursive triggers?
Aka, triggers that run as result of a change by a trigger.
Regards,
Peter Bartholdsson
24 matches
Mail list logo
