Postgres Asynchronous commit

The 1C:Enterprise developers forum

Pages: 1

Alexey Gerasimov

People who like this: 0 Yes / 0 No

Jun 01, 2017 05:24 PM

Interested

Rating: 32
Joined: Oct 27, 2011
Company: Abaco Soluciones S.A.

Quote

Asynchronous commit is an option that allows transactions to complete more quickly, at the cost that the most recent transactions may be lost if the database should crash. In many applications this is an acceptable trade-off.

As described in the previous section, transaction commit is normally synchronous: the server waits for the transaction's WAL records to be flushed to permanent storage before returning a success indication to the client. The client is therefore guaranteed that a transaction reported to be committed will be preserved, even in the event of a server crash immediately after. However, for short transactions this delay is a major component of the total transaction time. Selecting asynchronous commit mode means that the server returns success as soon as the transaction is logically completed, before the WAL records it generated have actually made their way to disk. This can provide a significant boost in throughput for small transactions.

Is it dangerous to use with 1c? I mean would it just loose last document posting or it could damage some database integrity?

Edited: Alexey Gerasimov - Jun 01, 2017 05:25 PM

Yulia Ivanova

People who like this: 0 Yes / 0 No

Jun 02, 2017 04:57 AM

Active user

Rating: 7
Joined: Nov 3, 2011
Company: 1C Company

Alexey, the document that you quoted (a PostgreSQL manual) contains the answer to your question:

Quote

The risk that is taken by using asynchronous commit is of data loss, not data corruption. If the database should crash, it will recover by replaying WAL up to the last record that was flushed. The database will therefore be restored to a self-consistent state, but any transactions that were not yet flushed to disk will not be reflected in that state. The net effect is therefore loss of the last few transactions. Because the transactions are replayed in commit order, no inconsistency can be introduced — for example, if transaction B made changes relying on the effects of a previous transaction A, it is not possible for A's effects to be lost while B's effects are preserved.

You can reduce the risk of data loss by improving the reliability of your servers.

Alexey Gerasimov	#3 People who like this: 0 Yes / 0 No Jun 02, 2017 12:46 PM
Interested Rating: 32 Joined: Oct 27, 2011 Company: Abaco Soluciones S.A.	Yulya, I understand what could possible happen to postgres, the question is what about 1c? For example, if the system shuts down improperly Totals recalculation could be needed. I understand that I am loosing one or some last transactions in db, I don't quite understand is this could possibly drive to 1c logical inconsistency. We have very reliable servers (one physical PSU problem during 5 years and it is now redundant), so I am evaluating this option as a free "upgrade" in performance.

Yulia Ivanova	#4 People who like this: 0 Yes / 0 No Jun 05, 2017 05:07 AM
Active user Rating: 7 Joined: Nov 3, 2011 Company: 1C Company	Alexey, it's really hard to predict. If you need to recover your system after an unexpected server outage, it is wise to run infobase verification and repair (and yes, this includes the recalculation of totals). And of course you should back up your database regularly just in case (see PostgreSQL documentation for details about database backup).

Pages: 1

Users browsing this topic (guests: 2, registered: 0, hidden: 0)