Re: If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back?
От | Michael Paquier |
---|---|
Тема | Re: If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back? |
Дата | |
Msg-id | CAB7nPqTNa9qPdcHRzhymy9qJ6VXHSGq9ORNcJerQrLGDyu+Ffw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back? (Tatsuo Ishii <ishii@postgresql.org>) |
Список | pgsql-hackers |
On Wed, Jun 8, 2016 at 7:43 PM, Tatsuo Ishii <ishii@postgresql.org> wrote: >> Hi, >> >> I'm researching the synchronous replication. I see the backend of the >> Primary Server calls SyncRepWaitForLSN() to wait for the Standby Server to >> write the WAL records. >> >> If some thing happens, such as network failure or disk failure, causes the >> Standby Server fail to receive WAL records or fail to write WAL records, >> would the backend of the Primary Server catch and handle this failure? >> Would the backend roll-back the transactions? Would the backend continue to >> work? > > I don't think the backend would roll back the transaction because when > SyncRepWaitForLSN() is called, the transaction has been already > committed. There's no way to roll back a transaction which has been > committed. Confirmed. The transaction is not rolled back and is considered committed locally. Don't count of course on statement_timeout to stop the transaction from being stuck. -- Michael
В списке pgsql-hackers по дате отправления: