On Tue, Jan 11, 2011 at 12:23, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, 2011-01-11 at 11:28 +0100, Magnus Hagander wrote:
>> >>> >>
>> >>> >> (You'd need a 4th mode for WAITING or so, to indicate it's waiting for
>> >>> >> a command)
>> >>> >
>> >>> > That's something different.
>> >>> >
>> >>> > The 3 phases are more concrete.
>> >>> >
>> >>> > BACKUP --> CATCHUP<---> STREAM
>> >>> >
>> >>> > When you connect you either do BACKUP or CATCHUP. Once in CATCHUP mode
>> >>> > you never issue a BACKUP. Once we have caught up we move to STREAM. That
>> >>> > has nothing to do with idle/active.
>> >>>
>> >>> So how does a walsender that's waiting for a command from the client
>> >>> show up? Surely it's not in "catchup" mode yet?
>> >>
>> >> There is a trivial state between connect and first command. If you think
>> >> that is worth publishing, feel free. STARTING?
>> >
>> > I think it's worth publishing. STARTING would be OK, or maybe STARTUP
>> > to parallel the other two -UP states.
>>
>> Here's a patch for this. I chose IDLE, because that's what we call
>> other backends that are waiting for commands...
>>
>> Does this seem correct?
>
> No
>
> You can be "idle" yet in STREAMING mode. What mode we are in has nothing
> to do with idle/active. Either STARTING/STARTUP/NULL but not IDLE.
>
> If you want that as well, then we need a second column, but personally
> it's too much information and its too hard to say what it actually
> means. For example, with sync rep, the WALSender might be idle, yet
> there might yet be backends waiting for a reply.
That's a good point.
Just to be clear, you're objecting to the *name* of the state, right,
not how/where it's set? In particular, how the catchup/streaming
things are set?
I agree that using a second column for it is unnecessary.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
