Re: [GENERAL] Understanding pg_last_xlog_receive_location
От | Michael Paquier |
---|---|
Тема | Re: [GENERAL] Understanding pg_last_xlog_receive_location |
Дата | |
Msg-id | CAB7nPqTUw2=+3_QP4Nt9OpufbWYT=vEtUg_JvxH_XF+q_iFsNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] Understanding pg_last_xlog_receive_location (Zach Walton <zacwalt@gmail.com>) |
Ответы |
Re: [GENERAL] Understanding pg_last_xlog_receive_location
|
Список | pgsql-general |
On Thu, Mar 2, 2017 at 5:53 AM, Zach Walton <zacwalt@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
В списке pgsql-general по дате отправления: