> On Sep 16, 2024, at 13:24, veem v <veema0000@gmail.com> wrote:
> Architecture team is suggesting to enable asynch io if possible, so that the streaming client will not wait for the
commitconfirmation from the database. So I want to understand , how asynch io can be enabled and if any downsides of
doingthis?
"Async I/O" has a specific meaning that's not currently applicable to PostgreSQL. What is available is
"synchronous_commit". This setting is by default on. When it's on, each commit waits until the associated WAL
informationhas been flushed to disk, and then returns. If it is turned off, the commit returns more or less
immediately,and the WAL flush happens asynchronously from the commit.
The upside is that the session can proceed without waiting for the WAL flush. The downside is that on a server crash,
sometransactions may not have been fully committed to the database, and will be missing when the database restarts.
Thedatabase won't be corrupted (as in, you try to use it and get errors), but it will be "earlier in time" than the
applicationmight expect. It's pretty common to turn it off for high-ingestion-rate situations, especially where the
applicationcan detect and replay missing transactions on a crash.
