Re: Urgent :: Postgresql streaming replication issue - sync mode

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Jason Wang <jasonwang(dot)public(at)gmail(dot)com>, Shital A <brightuser2019(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Urgent :: Postgresql streaming replication issue - sync mode
Date: 2019-10-03 15:34:06
Message-ID: 570b37b59153953b39ac7b279d17095458c055d2.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 2019-10-04 at 00:34 +1000, Jason Wang wrote:
> I read this
> https://www.2ndquadrant.com/en/blog/evolution-fault-tolerance-postgresql-synchronous-commit/
>
> But don't see why your primary would have more records than the
> standby?
>
> If killall was issued before commit returned, that means the
> transaction wasn't completed so yes you would lose records after last
> commit but that's expected; if commit was returned both primary and
> standby should have the transaction.
>
> Are you sure in your case you end up with primary and standby with
> different records from a single transaction?

PostgreSQL synchronous streaming replicatoin doesn't use anything like
two-phase commit.

1. It commits the transaction locally first, which generates WAL.
2. The WAL gets replicated.
3. As soon as the standby reports success, COMMIT returns.

If there is a failure after the first step completed, the
transaction will be committed locally, but not on the standby.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message bhargav kamineni 2019-10-03 15:53:01 Re: PMChildFlags array
Previous Message Jason Wang 2019-10-03 14:34:14 Re: Urgent :: Postgresql streaming replication issue - sync mode