You're right, restart_lsn on slave does not changes.
> What's using it?
As I think, streaming replication is using this slot. Does anybody know how
to fix it ?
вт, 16 мар. 2021 г. в 17:44, Tom Lane <t...@sss.pgh.pa.us>:
> Andrew Anderson <forumwriter...@gmail.com> writes:
> >> - replication slot (you said that is not it)
>
> > The replication slot is the same on master:
> > postgres=# select * from pg_replication_slots ;
> > slot_name | plugin | slot_type | datoid | database | temporary |
> > active | active_pid | xmin | catalog_xmin | restart_lsn |
> > confirmed_flush_lsn
> >
> ------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+--------------+---------------------
> > stanby_slot | | physical | | | f | t
> > | 94341 | | | 145/F6ECC190 |
> > (1 row)
> > $ grep slot ${PGDATA}/recovery.done
> > primary_slot_name = 'stanby_slot'
>
> > and on slave:
> > postgres=# select * from pg_replication_slots ;
> > slot_name | plugin | slot_type | datoid | database | temporary |
> > active | active_pid | xmin | catalog_xmin | restart_lsn |
> > confirmed_flush_lsn
> >
> ------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+--------------+---------------------
> > stanby_slot | | physical | | | f | f
> > | | | | 13E/981E2DD0 |
> > (1 row)
> > $ grep slot ${PGDATA}/recovery.conf
> > primary_slot_name = 'stanby_slot'
>
> Uh ... that slot's restart_lsn seems to correspond to where the
> standby is refusing to truncate WAL beyond. So I think your
> problem is exactly that this slot isn't advancing. What's
> using it?
>
> regards, tom lane
>
