
Niall Douglas wrote:
No such thing.
It sure is. For example, https://sqlperformance.com/2014/04/io-subsystem/delayed-durability-in-sql-se....
"Delayed durability" is not what traditionally the letter D in ACID means. It means that if the insert call has returned, the insert is in the database, period. It makes no provisions for up to 5 minutes of inserts being lost. This is simply not durable by the standard definition.
Consistency refers to the referential integrity of the database. ... So if transaction A updates references which are used by transaction B, and if after power loss transaction A was damaged and transaction B was not, if you are Consistent then you also need to throw away transaction B during recovery. But if transaction B did not use any inputs from modifications by transaction A, then if you are Durable you MUST recover transaction B even though it occurred after the damaged transaction A which is thrown away.
One definition of the letter C in ACID is that if you have issued transaction B after transaction A, the database is in one of three possible states: (none of A and B present), (A present), (both A and B present). It doesn't matter what references A or B update. You're absolutely not allowed to apply B without A on recovery. It's true that this meaning of consistency is not universally accepted. If you interpret C loosely, you have no letter with which to describe the above, which would now fall somewhere between C and D. So it probably makes sense to call it "delayed durability" if you consider "consistency" not that. As far as I can see, NuDB claims this exact property, subject to "NuDB's database integrity guarantees are only valid if the implementation of sync assures that all data is fully written to the underlying file before the call returns." "NuDB's database integrity guarantees are only valid if the implementation of trunc assures that subsequent calls to size will return o, even if the program is terminated or the device is taken offline before calling size." so I'm not quite sure what your objections are. You insist on him not calling NuDB durable, which he never did.