On 24 December 2015 at 20:15, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes <jeff.ja...@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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
