From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Zach Walton <zacwalt(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Understanding pg_last_xlog_receive_location |
Date: | 2017-03-02 00:36:26 |
Message-ID: | CAB7nPqTUw2=+3_QP4Nt9OpufbWYT=vEtUg_JvxH_XF+q_iFsNw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | priyanka raghav | 2017-03-02 06:01:01 | Load a csv to remote postgresql database |
Previous Message | Nikolai Zhubr | 2017-03-01 21:43:30 | Re: Re: Causeless CPU load waves in backend, on windows, 9.5.5 (EDB binary). |