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
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
On Wed, 2019-10-02 at 23:58 +0530, Shital A wrote:
> We are seeing a strange issue with postgresql streaming application
> in sync mode.
>
> We are using postgresql 9.6. Old version because of some specific
> requirements. We have setup cluster with master-standby using
> pacemaker.
>
> When w
On Thu, 3 Oct 2019, 03:10 Jason Wang, wrote:
> I think when you use kill -9 it wouldn't give any chance for postgres to
> do what it normally does. So in your case, the db was killed with no chance
> to apply to remote then it would be up to the recovery to decide how to
> handle the extra data a
On Thu, 3 Oct 2019, 00:08 Ravi Krishna, wrote:
> >
> > As the failed primary is having more data, How is it possible that
> primary is committing transaction before they were applied on standby with
> synchronous_commit=remote_apply?
>
> If I am not mistaken remote_apply is only from ver 11.
>
H
>
> As the failed primary is having more data, How is it possible that primary is
> committing transaction before they were applied on standby with
> synchronous_commit=remote_apply?
If I am not mistaken remote_apply is only from ver 11.
Hello,
We are seeing a strange issue with postgresql streaming application in sync
mode.
We are using postgresql 9.6. Old version because of some specific
requirements. We have setup cluster with master-standby using pacemaker.
When we kill master using killall -9 postgres. The failed primary h
