On Jan13, 2014, at 22:30 , "Joshua D. Drake" <jd@commandprompt.com> wrote:
> 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.
We *have* to "recover" waiting transaction upon switching off sync rep.
A transaction that waits for a sync standby to respond has already committed
locally (i.e., updated the clog), it just hasn't updated the proc array yet,
and thus is still seen as in-progress by the rest of the system. But rolling
back the transaction is nevertheless *impossible* at that point (except by
PITR, and hence the quoted around reciver). So the only alternative to
"recovering" them, i.e. have them abort their waiting, is to let them linger
indefinitely, still holding their locks, preventing xmin from advancing, etc,
until either the client disconnects or the server is restarted.
best regards,
Florian Pflug