The portion before the slash is the actual WAL file itself that it got to start replaying, usually the last few characters of the WAL file name. The portion after the slash is the position in the WAL file itself. Default size of each WAL is 16MB, so if that first portion doesn't match the primary, you can count back that many WAL files x16MB. If it's on the same WAL file, I'm not really sure how to get a more precise byte lag than that.
Thanks Keith I am looking something like the solution you suggested.
Once I run pg_controldata on the slave data directory it will be give me the latest checkpoint like below. Can you let me know a bit more detail on how can I get the approximate lag in the slave in bytes from this?
That I know, if standby is down, you cannot know exactly the last applied transaction log file.
But you could get a gross estimate if you check how many WAL files is the standby behind, just listing the WAL files on the master and on the standby.
Given that you can login on the standby machine.
regards,
fabio pardi
On 18/06/18 14:43, Debraj Manna wrote:
Is it possible to figure out the replication lag from transaction log files in the slave and master without querying postgres on the slave? Basically figuring out the replication lag in a slave when the postgres is down in that slave.
