Logging in mongodb and postgresql - do I understand it correctly?

Question

PostgreSQL

digging mongodb here and found that there is a storage.journal.commitIntervalMs setting that configures to save the journal every 50ms
mongodb key, she answers him that she saved it, he continues to do something, being sure that the key is saved, and at this time, without waiting for the next save to the log disk, everything falls and we lose the key?
then at update we see a certain writeConcern - https://docs.mongodb.com/manual/reference/write-co... where there is a j: true key that seems to force the log to be saved.
does this solve this problem?
and then I remembered that postgresql has a parameter wal_writer_delay = 200ms, what happens and postgresql can have such tops that the client thinks that the line is saved and everything was covered before the log was flushed to disk ???
plz enlighten!

Answer 1

Precisely about the current monga, I find it difficult to say something.
About the older version quote about the second version of monga
Responds "written" when the data has not even left the client's machine, let alone written anywhere.
With this approach, did the authors think about data loss at all and is it fixed now?
If you intentionally unscrew the synchronous_commit.
fsync is very expensive. Even on an SSD.
Since it is expensive, some tricks are made. Magnetic disks hate random writes and are much better suited to sequential writes. Therefore, here, too, they come up with some tricks.
As a result, postgresql (if you didn’t shoot yourself in the foot) writes wal to memory, a separate process wakes up every wal_writer_delay, flushes the accumulated wal to disk and notes at what position wal is guaranteed to reach the fsync disk. Because synchronous_commit is enabled, the worker waits until its data has been written to disk before responding to a "written" client. After that, the application responds with "recorded".
https://www.postgresql.org/docs/current/static/run...

synchronous_commit (enum) Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a "success" indication to the client

Answer 2

and then I remembered that postgresql has a parameter wal_writer_delay = 200ms, what happens and postgresql can have such tops that the client thinks that the line is saved and everything was covered before the log was flushed to disk ???
By postgres. If synchronous_commit = on is enabled, then in any case, before informing the client about success, we wait for the WAL to be written to disk. These are default and almost always reasonable settings.
In the case of synchronous_commit = off, it is only guaranteed that the database, even in the event of a meteorite fall, will remain in a consistent state, but WAL will be written to disk after some time, depending on the wal_writer_delay setting. This is the "willing to take the chance of data loss on crash in exchange for increased performance".