Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
От | Simon Riggs |
---|---|
Тема | Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication) |
Дата | |
Msg-id | AANLkTi=tBMFEhCKy3L6F7FOtg-2o0E32BYAiN1n04OZB@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 Wed, Mar 23, 2011 at 7:29 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Mar 23, 2011 at 2:43 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> On Wed, Mar 23, 2011 at 6:22 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> On Wed, Mar 23, 2011 at 12:10 PM, Simon Riggs <simon@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. >> >> No its not. >> >>> 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. >> >> As of 9.1, we now support other tools that use the protocol, so you >> cannot assume you know what is being sent, just because one sender has >> certain characteristics. > > Oh, really? Is this strictly hypothetical or is such a beast > planned/already in existence? Ask Magnus. In any case, that's not the only argument for keeping it. We introduce the view in this release and I would like it to stay the same from now, since we know we will need that info later. No more minor tweaks, please. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: