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.
Cheers,
Jeff