Re: Standalone synchronous master

Jim C. Nasby <jim@nasby.net>

From: Jim Nasby <jim@nasby.net>
To: "Joshua D. Drake" <jd@commandprompt.com>, Hannu Krosing <hannu@2ndQuadrant.com>, Florian Pflug <fgp@phlo.org>, Josh Berkus <josh@agliodbs.com>
Cc: Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, MauMau <maumau307@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kevin Grittner <kgrittn@ymail.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, Simon Riggs <simon@2ndquadrant.com>, Rajeev rastogi <rajeev.rastogi@huawei.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-01-13T21:14:21Z
Lists: pgsql-hackers
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.
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net