Re: system views for walsender activity - Mailing list pgsql-hackers

From Robert Haas
Subject Re: system views for walsender activity
Date
Msg-id AANLkTimH43xCBVH1JW8Nb-LSCWyc03YnaiHUScCa4jGH@mail.gmail.com
Whole thread Raw
In response to Re: system views for walsender activity  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: system views for walsender activity  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: GIN indexscans versus equality selectivity estimation
Next
From: Tom Lane
Date:
Subject: Re: GIN indexscans versus equality selectivity estimation