Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
От | Fujii Masao |
---|---|
Тема | Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication) |
Дата | |
Msg-id | AANLkTikfGngoxGfHK6jjR68P=aaMS7w=Vp476d1Dqgip@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: making write location work (was: Efficient
transaction-controlled synchronous replication)
|
Список | pgsql-hackers |
On Fri, Mar 25, 2011 at 6:11 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Mar 24, 2011 at 2:28 PM, Simon Riggs <simon@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 Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: