On 2014-01-13 15:14:21 -0600, 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'd be a fairly simple patch to re-check the state of syncrep config in SyncRepWaitForLsn(). Alternatively you can just write code to iterate over the procarray and sets Proc->syncRepState to SYNC_REP_WAIT_CANCELLED or such. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers