| From: | Venkata Balaji N <nag1010(at)gmail(dot)com> |
|---|---|
| To: | Colin Morelli <colin(dot)morelli(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Logical Decoding Failover |
| Date: | 2016-08-10 02:17:54 |
| Message-ID: | CAEyp7J_S9LfHwZHbnqnurbpsZy=0aNsGmsLTg5UB7qCtjXxN3A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> Now the logical decoding client connects to B (the new primary). The
> replication slot doesn't exist. So, it creates it and starts streaming.
> This is where the problem lies - as it would begin streaming from LSN 4
> (anything after what has already been committed), because I have no way
> (that I can find) of restoring my "progress" through the WAL on a the
> replicas.
>
> As a result, my application never sees the event at LSN 3. In fact, I'm
> not even sure how I could manually do this.
>
Yes, that is the current limitation and as of i know, there is no such
patch being developed at the moment. I leave it to any of the developers to
respond. This cannot be done manually as the new master will not read
through from
LSN 3 (which is a thing of past unknown to new master) and replication slot
at standby is a new one with the latest starting from LSN 4 which, the
logical decoder does not know.
Hope that helps !
Regards,
Venkata B N
Fujitsu Australia
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2016-08-10 07:53:51 | Re: Logical Decoding Failover |
| Previous Message | rob stone | 2016-08-10 02:08:58 | Re: permissions PostgreSQL 9.5 |