Re: Standalone synchronous master - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Standalone synchronous master
Date
Msg-id 52D4572D.2040802@nasby.net
Whole thread Raw
In response to Re: Standalone synchronous master  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Standalone synchronous master  (Andres Freund <andres@2ndquadrant.com>)
Re: Standalone synchronous master  ("Joshua D. Drake" <jd@commandprompt.com>)
List 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
turnoff 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Next
From: Andres Freund
Date:
Subject: Re: Standalone synchronous master