So, right now I have configuration of replication slots:
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/FBAACBA8 |
(1 row)
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)
And I can do 'select pg_drop_replication_slot('stanby_slot');' on slave
without any risk to destroy streaming replication ? And will it fix the
automated removing of WAL-files ?
вт, 16 мар. 2021 г. в 19:39, Tom Lane <[email protected]>:
> Andrew Anderson <[email protected]> writes:
> >> What's using it?
>
> > As I think, streaming replication is using this slot. Does anybody know
> how
> > to fix it ?
>
> Unless you need another replica that's downstream of the standby,
> you should not be maintaining a replication slot on the standby.
>
> There may be a way to have a slot that's not actually holding back
> WAL cleanup while doing nothing, but I don't know what it is.
>
> regards, tom lane
>
