From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: system views for walsender activity |
Date: | 2011-01-10 15:41:22 |
Message-ID: | 1294674082.12610.2379.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2011-01-10 at 17:05 +0200, Heikki Linnakangas wrote:
> On 10.01.2011 16:49, Simon Riggs wrote:
> > On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
> >> On Sun, Jan 9, 2011 at 15:53, Simon Riggs<simon(at)2ndquadrant(dot)com> wrote:
> >>> On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
> >>>
> >>>> One thing I noticed is that it gives an interesting property to my
> >>>> patch for streaming base backups - they now show up in
> >>>> pg_stat_replication, with a streaming location of 0/0.
> >>>>
> >>>> If the view is named pg_stat_replication, we probably want to filter
> >>>> that out somehow. But then, do we want a separate view listing the
> >>>> walsenders that are busy sending base backups?
> >>>>
> >>>> For that matter, do we want an indication that separates a walsender
> >>>> not sending data from one sending that happens to be at location 0/0?
> >>>> Most will leave 0/0 really quickly, but a walsender can be idle (not
> >>>> received a command yet), or it can be running IDENTIFY_SYSTEM for
> >>>> example.
> >>>
> >>> 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?
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira de Oliveira | 2011-01-10 15:48:03 | Re: system views for walsender activity |
Previous Message | Tom Lane | 2011-01-10 15:25:12 | Re: GIN indexscans versus equality selectivity estimation |