On Tue, Aug 14, 2018 at 6:13 PM Alek Paunov wrote:
> I am curious, Did you considered adapting writing in your use-case to
> Bedrock? AFAIK, you can read from Bedrock instance DBs safely without
> further adaptation.
>
Right, Bedrock is amazing, but in this particular use-case the only
NFS is a Remote/Network File System.
iSCSI is a local file system.
iSCSI is just transporting the SCSI protocol over a "different" physical layer
sort of like how you can transport SCSI over really really fat parallel SCSI
cables, PATA cables, or SATA cables. (That is, pSCSI, sSCSI, and
On Mon, Jul 23, 2018 at 3:57 AM Dan Kennedy wrote:
> On 07/22/2018 07:48 PM, Victor Costan wrote:
> > In a custom SQLite build, SQLITE_DEFAULT_LOOKASIDE results in compilation
> > errors, unless used with SQLITE_OMIT_COMPILEOPTION_DIAGS.
> >
> > This is because src/ctime.c includes the following
Read all of this repeatedly. Excellent post.
But if your nfs solution is configured not to lie, to honour lock and sync
Had to pop up here briefly. I ran into a number of problems with nfs
clients of various types wherein the most brutal would be VMware ESXi
hosts. Running backend network
Good day altogether,
I suppose there might be a problem with reporting missing indexes on
foreign key columns in conjunction with the without rowid clause:
C:\Users\Bernd>sqlite3
SQLite version 3.24.0 2018-06-04 19:24:41
Enter ".help" for usage hints.
Connected to a transient in-memory
On 14 Aug 2018, at 3:09pm, Clemens Ladisch wrote:
> However, there are other file
> operations that are properly synchronized, e.g., it is not possible for two
> NFS clients to create a directory with the same name.
You are correct. But there's still a problem with simulating a mutex system.
FWIW in the building I work in we have 20-30 users hitting around a dozen
SQLite DBs 8 hours a day 5 days a week, with all DBs served over nfs. The
number of corruptions I've seen in the last 5 years which nfs *might* be
responsible for is *very low*. The number of corruptions where nfs was
On 2018-08-14 16:07, Wout Mertens wrote:
Is there a way to use safely sqlite in this situation, perhaps by using
extra lock files or some other additional mechanism?
One solution I can think of involves sending all writes through a single
master, via files describing changes and lots of
On 8/14/18, Kris Adler wrote:
> So my question is: if I bind a value to the $key1 host parameter that makes
> the json_extract expression match one used in an index-on-expression,
> should the query planner then make use of the index-on-expression after the
> statement is recompiled?
I'm
The PostgreSQL documentation recommends against using the
constraint-name syntax. I decided to encourage their recommendation
by not supporting that feature.
On 8/14/18, Jordan Owens wrote:
> Hi,
>
> In reviewing the documentation for UPSERT, it does not appear that it fully
> supports the
Awesome, thanks!
On Tue, Aug 14, 2018 at 11:16 AM Richard Hipp wrote:
> On 8/14/18, Richard Hipp wrote:
> > I will strive to bring the behavior of SQLite into
> > alignment with PostgreSQL.
>
> Now fixed on trunk
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
Hi,
In reviewing the documentation for UPSERT, it does not appear that it fully
supports the PostgreSQL syntax. PostgreSQL provides an option to use the
name of a constraint instead of a list of columns or index expressions.
For example:
CREATE TABLE t1(a INTEGER PRIMARY KEY, b INT, c INT, d
I'm using a SQLite database with a single-table schema. The table includes
a column for JSON data. I have some shared logic that queries for rows
where various JSON fields match some value. So I have a generic query like
the following:
SELECT thing_data FROM thing WHERE json_extract(thing_data,
On 8/14/18, Richard Hipp wrote:
> I will strive to bring the behavior of SQLite into
> alignment with PostgreSQL.
Now fixed on trunk
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
Wout Mertens wrote:
> I know that multi-writer sqlite and NFS don't play well with each other.
>
> However, I wonder if some constraints could be added that would make this
> situation safe.
NFS locking implementations tend to be bad. However, there are other file
operations that are properly
Have you read through this document:
https://www.sqlite.org/howtocorrupt.html
On Tue, Aug 14, 2018 at 9:46 AM, Wout Mertens
wrote:
> In the meantime I found this discussion from 2011 about sqlite on CIFS:
> http://sqlite.1065341.n5.nabble.com/How-to-make-SQLite-
>
In the meantime I found this discussion from 2011 about sqlite on CIFS:
http://sqlite.1065341.n5.nabble.com/How-to-make-SQLite-run-safely-on-CIFS-mounted-file-system-tt37415.html#none
Basically using any networked filesystem as a backing store for sqlite is
madness? I imagine not much about that
Idle musing again, I'm pretty bad at dropping thoughts that are not
immediately applicable to me, sorry.
I know that multi-writer sqlite and NFS don't play well with each other.
However, I wonder if some constraints could be added that would make this
situation safe.
My problem space is that of
> On Aug 14, 2018, at 12:57 PM, Richard Hipp wrote:
>
> I will strive to bring the behavior of SQLite into alignment with PostgreSQL.
If only all this energy was spent on a proper MERGE clause instead… sigh… :D
___
sqlite-users mailing list
Simplified test case:
CREATE TABLE t1(a INTEGER PRIMARY KEY, b INT, c INT, d INT);
CREATE UNIQUE INDEX t1b ON t1(b);
INSERT INTO t1(a,b,c,d) VALUES(1,2,3,4);
SELECT * FROM t1;
INSERT INTO t1(a,b,c,d) VALUES(1,2,33,44)
ON CONFLICT(b) DO UPDATE SET c=excluded.c;
The second INSERT fails raises a
Hello,
I believe I have discovered a bug with UPSERT when a table has a unique
partial index. I'm getting a constraint exception instead of the database
updating the record.
SQLite v3.24.0
*Error message:*
SQLite3::ConstraintException: UNIQUE constraint failed: alarms.id:
INSERT INTO
21 matches
Mail list logo
