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
