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? standby.h doesn't need to know the internals of LOCKTAG. It just needs to declare a function that receives it as an opaque pointer. I don't know if that info helps resolve the situation, though. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
