The log unit are in bytes (though they are relative - so they aren't useful for measuring anything other than "offsets", and there sometimes can be "jumps" where there's a lot of skipped bytes), with the value being computed as:
If you take the output of: SELECT pg_current_xlog_location() you'll get something like:
70/A9002358
The part before the "/" is multiplied by 'ff000000' and added to the second part:
in python parlance (converting hex to into with the int('HEX',16) function) that might look like this:
int('ff000000',16)*int('70',16) + int('A9002358',16)
You could locate the current WAL file name in use using:
select pg_xlogfile_name(pg_current_xlog_insert_location());
Technically it's "possible" for a slave to catch up with the master if the log files that the slave needs are still available on the master. Of course, if the slave is replaying slowly it might never catch up - but you can measure if it is "catching up" or "falling behind" (sort of) using the query below:
On the slave you can get an idea of the time delay using the query:
SELECT extract(epoch from (now()-
pg_last_xact_replay_timestamp())) AS time_lag;
However, the number returned there is actually the "time since the last replayed transaction from the master" - so if the master hasn't had a transaction in awhile that "time" might make it seem like the slave is falling behind (when it reality, it is caught up, but there have been no transactions on the master.)