Re: pg_receivexlog --status-interval add fsync feedback - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: pg_receivexlog --status-interval add fsync feedback
Date
Msg-id CA+U5nMJYFQuO5yzh=AXG-q4eLnMqVmrty3GzsnODH9LqNMxmeQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_receivexlog --status-interval add fsync feedback  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: pg_receivexlog --status-interval add fsync feedback
List pgsql-hackers
On 10 October 2014 09:28, Fujii Masao <masao.fujii@gmail.com> wrote:

>>> In synchronous mode, pg_receivexlog should have similar logic as walreceiver does.
>>
>> OK. I understand that removing --fsync-interval has no problem.
>
> +1 for adding something like --synchronous option. To me,
> it sounds walreceiver-compatible mode rather than synchronous.
>
>>> Better to add a new "notify" message type. And pg_recevexlog should be prepared to receive it at any time. The
statusmight change on the fly, if the server's configuration is reloaded.
 
>>
>> OK. I'll consider it.
>
> I don't think that's good idea because it prevents us from using
> pg_receivexlog as async walreceiver (i.e., received WAL data is
> fsynced and feedback is sent back to the server soon,
> but transaction commit in the server doesn't wait for the feedback).

Sync rep works by setting parameters on the master. Standby servers
send replies by default, though you can turn replies off.

pg_receivexlog should work the same, but can't do this because it
doesn't know the fsync position unless it fsyncs.

So its not appropriate to have an option called "--synchronous" in the
same way that there is no parameter called "synchronous" on the
standby, for good reason.

A new parameter to send feedback should be called --feedback
A second parameter to decide whether to fsync should be called --fsync

if (feedback && fsync)  send fsynced LSN
else if (feedback)  send received LSN
; /* else send no feedback */

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: plpgsql - Assert statement
Next
From: Simon Riggs
Date:
Subject: Re: Improve automatic analyze messages for inheritance trees