Re: WAL-files is not removing authomaticaly

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Andrew Anderson <forumwriter007(at)gmail(dot)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
>