On Thu, Mar 24, 2011 at 3:22 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Mar 23, 2011 at 12:10 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> Specifically, if we're not going to remove write location, then I >>> think we need to apply something like the attached. >> >> The protocol supports different write/fsync values, so the view should >> display them. > > That's exactly the point. Currently, we have a protocol that supports > different write and fsync values, but the code as written does not > actually ever send a reply at any time when the two values can ever be > different. So there is no point in sending both of them. The write > location is completely redundant with the fsync location and therefore > completely useless. We shouldn't bother sending the value twice, or > displaying it twice, if it's absolutely 100% guaranteed to be > identical in every case. > > The point of the patch that I posted is that it restores the previous > behavior, where we send an update before flushing WAL and again after > flushing WAL. If we do that, then the write location can be ahead of > the flush location when we've written but not flushed. If we don't do > that, and only send replies after flushing everything, then the two > fields are perforce always the same on the master. I don't see that > as being a useful behavior, and in fact I think it could be quite > confusing. Someone might assume that if we bother to expose both a > write_location and a flush_location, they are somehow different.
I agree with Robert. It's useless and confusing to send the same location as flush_location as write_location redundantly. We should either remove write_location from the pg_stat_replication view and the protocol at all, or apply the proposed patch. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
