On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes <jeff.janes@gmail.com> wrote: >> >> On further thought, neither do I. The attached patch inverts >> ResolveRecoveryConflictWithLock to be called back from the lmgr code so that >> is it like ResolveRecoveryConflictWithBufferPin code. It does not try to >> cancel the conflicting lock holders from the signal handler, rather it just >> loops an extra time and cancels the transactions on the next call. >> >> It looks like the deadlock detection is adequately handled within normal >> lmgr code within the back-ends of the other parties to the deadlock, so I >> didn't do a timeout for deadlock detection purposes. > > I was testing that this still applies to git HEAD. And it doesn't due > to the re-factoring of lock.h into lockdef.h. (And apparently it > never actually did, because that refactoring happened long before I > wrote this patch. I guess I must have done this work against > 9_5_STABLE.) > > standby.h cannot include lock.h because standby.h is included > indirectly by pg_xlogdump. But it has to get LOCKTAG which is only in > lock.h. > > Does this mean that standby.h also needs to get parts spun off into a > new standbydef.h that can be included from front-end code?
That is how I've done it.
The lock cancel patch applies over the header split patch.
This looks good to me, apart from some WhitespaceCrime.
Header split applied, will test and apply the main patch this week.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
