On Fri, Mar 25, 2011 at 5:03 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Fri, Mar 25, 2011 at 6:11 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Mar 24, 2011 at 2:28 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> The protocol supports sending two values, so two are displayed. >>> >>> If you wish to remove one from the display then that only makes sense >>> if you also prevent the protocol from supporting two values. >>> >>> There is no benefit in doing that, so why do it? We are going to put >>> that back in 9.2 if you remove it now. Why not leave it, so we don't >>> need to rewrite all the monitoring tools that will use this view? > > What are you planning to use write_location for? BTW, I'm thinking to > add recv_location (not write_location) in 9.2 to support another sync rep > mode which makes transactions wait until the standby has received > (not fsync'd) the WAL. You're planning the same? > >> If we're going to put it back in 9.2, then we shouldn't remove it now. >> We should just make it work. It's a three line patch. If 9.2 is >> going to meaningfully distinguish between write location and flush >> location, then we may as well do the same thing in 9.1. Then we'll be >> ahead of the game: not only will the view have the same columns in >> both releases, but they'll actually have the same semantics in both >> releases. > > +1
I think we have adequate consensus on this topic, so committed. -- 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
