Search Postgresql Archives

Re: Understanding pg_last_xlog_receive_location

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.paquier@xxxxxxxxx> wrote:
On Thu, Mar 2, 2017 at 5:53 AM, Zach Walton <zacwalt@xxxxxxxxx> 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux