On 9 May 2012 03:52, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, May 08, 2012 at 10:29:31PM -0400, Aidan Van Dyk wrote:
>> On Tue, May 8, 2012 at 10:09 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>
>> >> And then, I could envision (if it continues down this road):
>> >> off
>> >> local
>> >> remote_accept
>> >> remote_write
>> >> remote_sync
>> >> remote_apply (implies visible to new connections on the standby)
>> >>
>> >> Not saying all off these are necessarily worth it, but they are all
>> >> the various "stages" of WAL processing on the remote...
>> >
>> > The _big_ problem with "write" is that we might need that someday to
>> > indicate some other kind of write, e.g. write to kernel, fsync to disk.
>>
>> Well, yes, but in the sequence of:
>> >> remote_accept
>> >> remote_write
>> >> remote_sync
>>
>> it is much more clear...
>>
>> With a single "remote_write", you can't tell just by itself it that is
>> intended to be "it's a write *to* the remote", or "it's a write *by*
>> the remote". But when combined with other terms, only one makes sense
>> in all cases.
>
> Yep. In fact, remote_write I thought meant a remote write, while it
> currently means a write to the remote. I like remote_accept.
The naming is not arbitrary. -1 to changing it as suggested.
It is as Aidan says, a state between receive and fsync, normally
referred to as write.
Plus the word remote denotes it is on the standby, not the local master.
So both words have specific meaning, and IMHO clear meaning.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
