On Thu, Feb 3, 2022, 10:32 AM Abhishek Bhola <abhishek.bh...@japannext.co.jp> wrote:
> So far I figured out that the problem is on the subscriber side. > The same publication, when subscribed to on another DB, works fine. > Also noticed that the remote_lsn value on the target DB is still 0/0. > > targetdb=# select * from pg_replication_origin_status ; > local_id | external_id | remote_lsn | local_lsn > ----------+---------------+----------------+---------------- > 1 | pg_3615756798 | 9E96/37152C80 | 1518C/9014BD98 > 2 | pg_3616584803 | 0/0 | 0/0 > (2 rows) > > Would really appreciate it if someone could help me with this. > > > > On Thu, Feb 3, 2022 at 9:53 AM Abhishek Bhola < > abhishek.bh...@japannext.co.jp> wrote: > >> Update: Tried dropping and recreating publication on the source DB and >> subscription still won't move ahead. >> Not sure what I am missing. >> >> On Wed, Feb 2, 2022 at 1:20 PM Abhishek Bhola < >> abhishek.bh...@japannext.co.jp> wrote: >> >>> The only statement I see on the target DB log is >>> "logical replication apply worker for subscription >>> ""sub_omx_archive_tci"" has started",,,,,,,,,"" >>> >>> I don't see the logical replication table synchronization worker started >>> for any of the tables in this subscription as I see in the other one. >>> >> This might help you track subscription state along with pg_stat_subscription. https://www.postgresql.org/docs/10/catalog-pg-subscription-rel.html It might be a huge table being 'copy' ed and writes would be slow due to too many indexes etc. https://postgresteam.slack.com/files/UQMFAU01W/F02V69YK59P/untitled.sql also if you see nothing is moving, you may want to login to the server and strace the worker processes pid to see if you see any movement at all or it keeps looping on some errors.
