Re: [HACKERS] If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back?

2016-06-08 Thread Michael Paquier
On Wed, Jun 8, 2016 at 7:43 PM, Tatsuo Ishii  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] If SyncRepWaitForLSN() fails, would the postgres backend do a roll-back?

2016-06-08 Thread Tatsuo Ishii
> 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.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers