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
On Thu, Mar 2, 2017 at 5:53 AM, Zach Walton 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
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
---+---+-
Thanks. We have some patches on the 9.4.5 code base (not in the replication
path). I'll work on porting those to 9.4.11 and will report back to the
thread.
On Wed, Mar 1, 2017 at 6:51 AM, Zach Walton wrote:
> I'm following the documentation here (using postgresql 9.4.5):
> https://www.postgresql.org/docs/9.4/static/functions-admin.html
You should really update to a newer version of 9.4.X, you are missing
more than 1 year of bug fixes by staying on 9
I'm following the documentation here (using postgresql 9.4.5):
https://www.postgresql.org/docs/9.4/static/functions-admin.html
I'm attempting to fully understand the interplay
between pg_is_in_recovery() + pg_last_xlog_receive_location() +
pg_last_xlog_replay_location() so we can devise a reliable
