Re: Spurious standby query cancellations

On 24 December 2015 at 20:15, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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