Re: Understanding pg_last_xlog_receive_location

Thanks Michael- That was indeed the issue. We have a very complex wrapper
application that walks the server through multiple state transitions, and
it turned out that in the state I was running the query from, streaming
replication wasn't configured.
On Wed, Mar 1, 2017 at 4:36 PM Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Thu, Mar 2, 2017 at 5:53 AM, Zach Walton <zacwalt(at)gmail(dot)com> wrote:
> > I was able to test 9.4.11 and am seeing the same behavior:
> >
> > postgres=# SELECT pg_is_in_recovery(), pg_last_xlog_receive_location(),
> > pg_last_xlog_replay_location();
> > pg_is_in_recovery | pg_last_xlog_receive_location |
> > pg_last_xlog_replay_location
> >
> -------------------+-------------------------------+------------------------------
> > t | | 0/3000198
>
> Okay, you said that you are using here streaming replication, but the
> standby you are performing this query on seems just to be a hot
> standby recovering WAL from a WAL archive, not via streaming. I would
> bet that there is no WAL receiver running.
> pg_last_xlog_receive_location() get the last WAL position received
> from a streaming node, something that is set to NULL if there is no
> streaming happening, while pg_last_xlog_replay_location() is set by
> the startup process when replaying WAL records.
>
> Again I see no bugs here, you should check if a WAL receiver is
> running on this standby server.
> --
> Michael
>