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.paqu...@gmail.com> wrote:
> On Thu, Mar 2, 2017 at 5:53 AM, Zach Walton <zacw...@gmail.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 >
