Re: Movement of restart_lsn position movement of logical replication slots is very slow

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Jammie <shailesh(dot)jamloki(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Movement of restart_lsn position movement of logical replication slots is very slow
Date: 2020-12-15 13:02:18
Message-ID: CAA4eK1+2EAiffL1abpf=OjQ1JQC0SL=sVqHnjAUP+WpzbuZvqQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 15, 2020 at 11:00 AM Jammie <shailesh(dot)jamloki(at)gmail(dot)com> 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.
>
> git hub for APIs of pgJDBC methods available.
>
> https://github.com/pgjdbc/pgjdbc
>
> The second slot refers to "private" slot.
>
> So ""we are not doing reading from the stream' ==> It means that we are having readPending call only from the shared slot then we get the lastReceivedLSN() from stream and
> send it back to stream as confirmed_flush_lsn for both private and shared slot. We dont do readPending call to private slot. we will use private slot only when we dont have choice. It is kind of reserver slot for us.
>

I think this (not performing read/decode on the private slot) could be
the reason why it lagging behind. If you want to use as a reserve slot
then you probably want to at least perform
pg_replication_slot_advance() to move it to the required position. The
restart_lsn won't move unless you read/decode from that slot.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2020-12-15 13:12:40 Re: On login trigger: take three
Previous Message Laurenz Albe 2020-12-15 12:55:51 Re: Add session statistics to pg_stat_database