Re: Standalone synchronous master
От | Joshua D. Drake |
---|---|
Тема | Re: Standalone synchronous master |
Дата | |
Msg-id | 52D45ADF.4030907@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Standalone synchronous master (Jim Nasby <jim@nasby.net>) |
Ответы |
Re: Standalone synchronous master
|
Список | pgsql-hackers |
On 01/13/2014 01:14 PM, Jim Nasby wrote: > > On 1/13/14, 12:21 PM, Joshua D. Drake wrote: >> >> On 01/13/2014 10:12 AM, Hannu Krosing wrote: >>>>> In other words, if we're going to have auto-degrade, the most >>>>> intelligent place for it is in >>>>> RepMgr/HandyRep/OmniPITR/pgPoolII/whatever. It's also the *easiest* >>>>> place. Anything we do *inside* Postgres is going to have a really, >>>>> really hard time determining when to degrade. >>>> +1 >>>> >>>> This is also how 2PC works, btw - the database provides the building >>>> blocks, i.e. PREPARE and COMMIT, and leaves it to a transaction manager >>>> to deal with issues that require a whole-cluster perspective. >>>> >>> >>> ++1 >> >> +1 > > Josh, what do you think of the upthread idea of being able to recover > in-progress transactions that are waiting when we turn off sync rep? I'm > thinking that would be a very good feature to have... and it's not > something you can easily do externally. I think it is extremely valuable, else we have lost those transactions which is exactly what we don't want. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc "In a time of universal deceit - telling the truth is a revolutionary act.", George Orwell
В списке pgsql-hackers по дате отправления: