Re: Streaming replication status

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Streaming replication status
Дата
Msg-id 1269074963.3556.1375.camel@ebony
обсуждение исходный текст
Ответ на Re: Streaming replication status  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Streaming replication status  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Thu, 2010-01-14 at 17:33 +0900, Fujii Masao wrote:

> I added two new functions;
> 
> (1) pg_last_xlog_receive_location() reports the last WAL location received
>     and synced by walreceiver. If streaming replication is still in progress
>     this will increase monotonically. If streaming replication has completed
>     then this value will remain static at the value of the last WAL record
>     received and synced. When the server has been started without a streaming
>     replication then the return value will be InvalidXLogRecPtr (0/0).
> 
> (2) pg_last_xlog_replay_location() reports the last WAL location replayed
>     during recovery. If recovery is still in progress this will increase
>     monotonically. If recovery has completed then this value will remain
>     static at the value of the last WAL record applied. When the server has
>     been started normally without a recovery then the return value will be
>     InvalidXLogRecPtr (0/0).

I just noticed that these functions have almost the same name as
functions I wrote for Hot Standby and Heikki removed from that patch.
The function code and docs are 99% identical.

I'm happy that the code was used and it is BSD, though it does seem
strange to have this credited to others in the release notes.

>From May 2 2009 the patch included

+        <entry>
+
<literal><function>pg_last_recovered_xlog_location</function>()</literal>
+         </entry>
+        <entry><type>text</type></entry>
+        <entry>Returns the transaction log location of the last WAL
record
+         in the current recovery. If recovery is still in progress this
+         will increase monotonically. If recovery is complete then this value
will 
+         remain static at the value of the last transaction applied during
that
+         recovery. When the server has been started normally this will
return 
+         InvalidXLogRecPtr (0/0).
+         (zero).
+        </entry>

with code

+ /*
+  * Returns xlog location of last recovered WAL record.
+  */
+ Datum
+ pg_last_recovered_xlog_location(PG_FUNCTION_ARGS)
+ {
+     char        location[MAXFNAMELEN];
+ 
+     {
+         /* use volatile pointer to prevent code rearrangement */
+         volatile XLogCtlData *xlogctl = XLogCtl;
+ 
+         SpinLockAcquire(&xlogctl->info_lck);
+ 
+         LastRec = xlogctl->recoveryLastRecPtr;
+ 
+         SpinLockRelease(&xlogctl->info_lck);
+     }
+ 
+     snprintf(location, sizeof(location), "%X/%X",
+              LastRec.xlogid, LastRec.xrecoff);
+     PG_RETURN_TEXT_P(cstring_to_text(location));
+ }

-- Simon Riggs           www.2ndQuadrant.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [BUG] SECURITY DEFINER on call handler makes daemon crash
Следующее
От: Hitoshi Harada
Дата:
Сообщение: Re: 9.0 release notes done