Re: is sync rep stalled?
От | Heikki Linnakangas |
---|---|
Тема | Re: is sync rep stalled? |
Дата | |
Msg-id | 4CA42995.4060104@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: is sync rep stalled? (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: is sync rep stalled?
Re: is sync rep stalled? Re: is sync rep stalled? |
Список | pgsql-hackers |
On 29.09.2010 10:56, Fujii Masao wrote: > On Wed, Sep 29, 2010 at 11:47 AM, Robert Haas<robertmhaas@gmail.com> wrote: >> So we've got two patches that implement synchronous replication, and >> no agreement on which one, if either, should be committed. We have no >> agreement on how synchronous replication should be configured, and at >> most a tenuous agreement that it should involve standby registration. >> >> This is bad. >> >> This feature is important, and we need to get it done. How do we get >> the ball rolling again? Agreed. Actually, given the lack of people jumping in and telling us what they'd like to do with the feature, maybe it's not that important after all. > ISTM that it still takes long to make consensus on standby registration. > So, how about putting the per-standby parameters in recovery.conf, and > focusing on the basic features in synchronous replication at first? > During that time, we can deepen discussion on standby registration, and > then we can implement that. > > The basic features that I mean is for most basic use case, that is, one > master and one synchronous standby case. In detail, ISTM the problem is exactly that there is no consensus on what the basic use case is. I'm sure there's several things you can accomplish with synchronous replication, perhaps you could describe what the important use case for you is? >> * Support multiple standbys with various synchronization levels. > > Not required for that case. IMHO at least we'll still need to support asynchronous standbys in the same mix, that's an existing feature. >> * What happens if a synchronous standby isn't connected at the moment? Return immediately vs. wait forever. > > The wait-forever option is not required for that case. Let's implement > the return-immediately at first. > > ..- > >> * async, recv, fsync and replay levels of synchronization. > > At least one of three synchronous levels should be included in the first > commit. I think that either recv or fsync is suitable for first try > because those don't require wake-up signaling from startup process to > walreceiver and are relatively easy to implement. What is the use case for that combination? For zero data loss, you *must* wait forever if a standby isn't connected. For keeping a hot standby server up-to-date so that you can freely query the standby instead of the master, you need replay level synchronization. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Peter EisentrautДата:
Сообщение: Re: Unable to generate man pages for translated sgml