3 ms·

It's not, though, because fsync has no relation whatsoever to what other processes see. Durability is totally different from concurrency or multiprocess consis

It's not, though, because fsync has no relation whatsoever to what other processes see. Durability is totally different from concurrency or multiprocess consistency. There are already guarantees about how we can order reads and writes in a shared file. Very well defined guarantees -- ones we've built entire RDBMS systems on top of. Guaranteeing durability (persistence across a crash) is a totally separate problem from understanding write visibility between threads.

Animats 3y ago
> It's not, though, because fsync has no relation whatsoever to what other processes see. Ah, the SQLite people. I was thinking in terms of databases such as MySQL and Postgres where one process owns the files and client programs communicate with it.
- throwaway09223 3y ago
  It's the same for sqlite, postgres, mysql, or any other file. Syncing data to durable storage is totally unrelated to visibility guarantees between multiple threads or processes working within the same file (be it using write, mmap, whatever)
  - Animats 3y ago
    SQLite relies on file system visibility guarantees, because there are multiple processes connected only via the file system. But Postgres and MySQL have one process that touches the underlying file, so they can coordinate internally.
    - throwaway09223 3y ago
      Not really. It's often all just shared memory via mmap. The files are never closed, and sometimes never operated on with read/write because they're just mapped. This behavior is common between (eg) both sqlite and mysql. (Postgres defaults otherwise, but architecturally it is not different) The visibility issues you're raising, basically implementing views and transactions, would not be applicable to any of these systems. You're confusing durability guarantees (fsync, msync) with visibility guarantees -- the latter of which are just standard memory access issues.

Animats 3y ago

> It's not, though, because fsync has no relation whatsoever to what other processes see. Ah, the SQLite people. I was thinking in terms of databases such as MySQL and Postgres where one process owns the files and client programs communicate with it.

throwaway09223 3y ago
It's the same for sqlite, postgres, mysql, or any other file. Syncing data to durable storage is totally unrelated to visibility guarantees between multiple threads or processes working within the same file (be it using write, mmap, whatever)
- Animats 3y ago
  SQLite relies on file system visibility guarantees, because there are multiple processes connected only via the file system. But Postgres and MySQL have one process that touches the underlying file, so they can coordinate internally.
  - throwaway09223 3y ago
    Not really. It's often all just shared memory via mmap. The files are never closed, and sometimes never operated on with read/write because they're just mapped. This behavior is common between (eg) both sqlite and mysql. (Postgres defaults otherwise, but architecturally it is not different) The visibility issues you're raising, basically implementing views and transactions, would not be applicable to any of these systems. You're confusing durability guarantees (fsync, msync) with visibility guarantees -- the latter of which are just standard memory access issues.