| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Standby node using replication slot not visible in pg_stat_replication while catching up |
| Date: | 2014-03-10 12:06:53 |
| Message-ID: | CAB7nPqRxLcBc7CAiYrOD3-gMLLJO12xnA-XRboGoVr_VEPqUxg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi all,
I have been playing a bit with the replication slots, and I noticed a
weird behavior in such a scenario:
1) Create a master/slave cluster, and have slave use a replication slot
2) Stop the master
3) Create a certain amount of WAL, during my tests I played with 4~5GB of WAL
4) Restart the slave, it catches up with the WALs that master has
retained in pg_xlog.
I noticed that while the standby using the replication slot catches
up, it is not visible in pg_stat_replication on master. This makes
monitoring of the replication lag difficult to follow, particularly in
the case where the standby disconnects from the master. Once the
standby has caught up, it reappears once again in pg_stat_replication.
I didn't have a look at the code to see what is happening, but is this
behavior expected?
Regards,
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2014-03-10 12:11:36 | Re: WIP patch (v2) for updatable security barrier views |
| Previous Message | Christian Kruse | 2014-03-10 11:44:09 | Re: Patch: show relation and tuple infos of a lock to acquire |