On Tue, Jan 11, 2011 at 02:24, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jan 10, 2011 at 10:41 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> >>> I think we need a status enum. ('BACKUP', 'CATCHUP', 'STREAM') for the 3
>>> >>> phases of replication.
>>> >>
>>> >> That seems reasonable. But if we keep BACKUP in there, should we
>>> >> really have it called pg_stat_replication? (yeah, I know, I'm not
>>> >> giving up :P)
>>> >>
>>> >> (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?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
