location.
Regards
Shailesh
On Thu, 24 Dec, 2020, 7:43 pm Amit Kapila, wrote:
> On Thu, Dec 24, 2020 at 7:30 PM Jammie wrote:
> >
> > Sorry dont have the debug setup handy. However the sql commands now
> works though to move the restart_lsn of the slots in standlone code from
>
, 2020 at 12:29 PM Amit Kapila
wrote:
> On Wed, Dec 23, 2020 at 7:06 PM Jammie wrote:
> >
> > Thanks Amit for the response.
> > Two things :
> > 1) In our observation via PSQL the advance command as well do not move
> the restart_lsn immediately. It is simila
However when the situation comes and that one slot gets behind it never
recovers and no way to recover from this situation even after reading using
advance ro pg_logical_get_changes sql command.
On Wed, Dec 23, 2020 at 7:05 PM Jammie wrote:
> Thanks Amit for the response.
> Two things :
&
15, 2020 at 11:00 AM Jammie
> wrote:
> >
> > Thanks Amit for the response
> >
> > We are using pgJDBC sample program here
> > https://jdbc.postgresql.org/documentation/head/replication.html
> >
> > the setFlushLSN is coming from the pgJDBC only.
>
ctors that might cause delay in updating
restart_lsn of the slot ?
3) In PG -13 does this behaviour change ?
Regards
Shailesh
the s
On Mon, Dec 14, 2020 at 4:51 PM Amit Kapila wrote:
> On Mon, Dec 14, 2020 at 9:30 AM Jammie wrote:
> >
> > Hello,
> >
> > We hav
Hello,
We have two logical replication slots in our postgresql database
(version-11) instance and we are using pgJDBC to stream data from these two
slots. We are ensuring that when we regularly send feedback and update the
confirmed_flush_lsn (every 10 minutes) for both the slots to the same
posit
