Search Postgresql Archives

Re: WAL-files is not removing authomaticaly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andrew Anderson <forumwriter007@xxxxxxxxx> 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






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux