On Thu, Jan 12, 2012 at 3:09 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Jan 12, 2012 at 12:20 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> +static void
>>> +ProcessWalSndrMessage(XLogRecPtr walEnd, TimestampTz sendTime)
>>>
>>> walEnd is not used in ProcessWalSndrMessage() at all. Can't we remove it?
>>> If yes, walEnd field in WalSndrMessage is also not used anywhere, so ISTM
>>> we can remove it.
>>
>> It's there to allow extension of the message processing to be more
>> complex than it currently is. Changing the protocol is much harder
>> than changing a function call.
>>
>> I'd like to keep it since it doesn't have any negative effects.
>
> OK. Another problem about walEnd is that WalDataMessageHeader.walEnd is not
> the same kind of location as WalSndrMessage.walEnd. The former indicates the
> location that WAL has already been flushed (maybe not sent yet), i.e.,
> "send request
> location". OTOH, the latter indicates the location that WAL has
> already been sent.
> Is this inconsistency intentional?
WalSndrMessage isn't set to anything, its just a definition.
PrimaryKeepaliveMessage is a message type that uses WalSndrMessage.
That message type is only sent when the WalSndr is quiet, so what is
the difference, in that case?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
