Re: [HACKERS] Spurious standby query cancellations

2016-02-20 Thread Simon Riggs
On 24 December 2015 at 20:15, Jeff Janes wrote: > On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes wrote: > > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes > wrote: > >> > >> On further thought, neither do I. The attached patch inverts > >> ResolveRecoveryConflictWithLock to be called back from the

Re: [HACKERS] Spurious standby query cancellations

2016-02-20 Thread Amit Kapila
On Fri, Dec 25, 2015 at 1:45 AM, Jeff Janes wrote: > > On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes wrote: > > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes wrote: > >> > >> On further thought, neither do I. The attached patch inverts > >> ResolveRecoveryConflictWithLock to be called back from th

Re: [HACKERS] Spurious standby query cancellations

2016-02-01 Thread Alvaro Herrera
Simon Riggs wrote: > This looks good to me, apart from some WhitespaceCrime. > > Header split applied, will test and apply the main patch this week. Since the patch already appears to have a committer's attention, it's okay to move it to the next commitfest; if Simon happens to commit ahead of t

Re: [HACKERS] Spurious standby query cancellations

2016-01-20 Thread Simon Riggs
On 24 December 2015 at 20:15, Jeff Janes wrote: > On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes wrote: > > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes > wrote: > >> > >> On further thought, neither do I. The attached patch inverts > >> ResolveRecoveryConflictWithLock to be called back from the

Re: [HACKERS] Spurious standby query cancellations

2015-12-24 Thread Jeff Janes
On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes wrote: > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes 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 ResolveRecoveryConflictWithBuf

Re: [HACKERS] Spurious standby query cancellations

2015-12-23 Thread Jeff Janes
On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes 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

Re: [HACKERS] Spurious standby query cancellations

2015-12-23 Thread Michael Paquier
On Thu, Sep 24, 2015 at 3:33 PM, Jeff Janes wrote: > On Wed, Sep 16, 2015 at 2:44 PM, Simon Riggs wrote: >> >> On 14 September 2015 at 12:00, Jeff Janes wrote: >> It's now possible to fix this by putting a lock wait on the actual lock request, which wasn't available when I first w

Re: [HACKERS] Spurious standby query cancellations

2015-09-16 Thread Simon Riggs
On 14 September 2015 at 12:00, Jeff Janes wrote: > It's now possible to fix this by putting a lock wait on the actual lock >> request, which wasn't available when I first wrote that, hence the crappy >> wait loop. Using the timeout handler would now be the preferred way to >> solve this. We can

Re: [HACKERS] Spurious standby query cancellations

2015-09-14 Thread Jeff Janes
On Fri, Sep 4, 2015 at 3:25 PM, Simon Riggs wrote: > On 27 August 2015 at 22:55, Jeff Janes wrote: > >> In ResolveRecoveryConflictWithLock, there is the comment: >> >> /* >> * If blowing away everybody with conflicting locks doesn't work, >> after >> * the first two attempts then w

Re: [HACKERS] Spurious standby query cancellations

2015-09-04 Thread Simon Riggs
On 27 August 2015 at 22:55, Jeff Janes wrote: > In ResolveRecoveryConflictWithLock, there is the comment: > > /* > * If blowing away everybody with conflicting locks doesn't work, after > * the first two attempts then we just start blowing everybody away > until > * it does wor

[HACKERS] Spurious standby query cancellations

2015-08-27 Thread Jeff Janes
In ResolveRecoveryConflictWithLock, there is the comment: /* * If blowing away everybody with conflicting locks doesn't work, after * the first two attempts then we just start blowing everybody away until * it does work. But what it does is something different than that. At l