On Wed, Mar 9, 2011 at 9:21 PM, Bruce Momjian <br...@momjian.us> wrote: > Simon Riggs wrote: >> On Fri, 2011-03-04 at 23:15 +0900, Fujii Masao wrote: >> >> > postgres=# SELECT application_name, state, sync_priority, sync_state >> > FROM pg_stat_replication; >> > application_name | state | sync_priority | sync_state >> > ------------------+-----------+---------------+------------ >> > one | STREAMING | 1 | POTENTIAL >> > two | STREAMING | 2 | SYNC >> > (2 rows) >> >> Bug! Thanks. > > Is there a reason these status are all upper-case?
Not that I know of. However, I think that some more fundamental rethinking of the "state" mechanism may be in order. When Magnus first committed this, it would say CATCHUP whenever you were behind (even if only momentarily) and STREAMING if you were caught up. Simon then changed it so that it says CATCHUP until you catch up the first time, and then STREAMING afterward (even if you fall behind again). Neither behavior seems completely adequate to me. I think we should have a way to know whether we've ever been caught up, and if so when the most recent time was. So you could then say things like "is the most recent time at which the standby was caught up within the last 30 seconds?", which would be a useful thing to monitor, and right now there's no way to do it. There's also a BACKUP state, but I'm not sure it makes sense to lump that in with the others. Some day it might be possible to stream WAL and take a backup at the same time, over the same connection. Maybe that should be a separate column or something. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
