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
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 |