Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-26 Thread Thomas Munro
On Thu, Jun 21, 2018 at 10:29 AM, Andres Freund wrote: > On 2018-06-21 00:25:03 +1200, David Rowley wrote: >> On 19 June 2018 at 17:43, Thomas Munro wrote: >> > The problem is that StandbyReleaseLocks() does a linear search of all >> > known AccessExclusiveLocks when a transaction ends. Luckily,

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-20 Thread Andres Freund
Hi, On 2018-06-21 00:25:03 +1200, David Rowley wrote: > On 19 June 2018 at 17:43, Thomas Munro wrote: > > The problem is that StandbyReleaseLocks() does a linear search of all > > known AccessExclusiveLocks when a transaction ends. Luckily, since > > v10 (commit 9b013dc2) that is skipped for tra

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-20 Thread Thomas Munro
Hi David, On Thu, Jun 21, 2018 at 12:25 AM, David Rowley wrote: > On 19 June 2018 at 17:43, Thomas Munro wrote: >> The problem is that StandbyReleaseLocks() does a linear search of all >> known AccessExclusiveLocks when a transaction ends. Luckily, since >> v10 (commit 9b013dc2) that is skipped

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-20 Thread David Rowley
On 19 June 2018 at 17:43, Thomas Munro wrote: > The problem is that StandbyReleaseLocks() does a linear search of all > known AccessExclusiveLocks when a transaction ends. Luckily, since > v10 (commit 9b013dc2) that is skipped for transactions that haven't > taken any AELs and aren't using 2PC, b

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-20 Thread Thomas Munro
Adding Simon and David R. On Wed, Jun 20, 2018 at 5:44 AM, Tom Lane wrote: > Hence, I have a modest proposal: use elog(LOG) followed by Assert(false), > so that debug builds report such problems loudly but production builds > do not. We've done that before, see e.g. load_relcache_init_file aroun

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-19 Thread Tom Lane
Andres Freund writes: > On 2018-06-19 13:05:48 -0400, Robert Haas wrote: >> I don't expect you to agree with my vote, but I stand by it. > Yea, I didn't expect (but hoped!) to change your mind... ;) FWIW, I agree with Robert --- a PANIC here will certainly create problems, and it's much less cle

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-19 Thread Andres Freund
On 2018-06-19 13:05:48 -0400, Robert Haas wrote: > On Tue, Jun 19, 2018 at 1:01 PM, Andres Freund wrote: > > On 2018-06-19 10:45:04 -0400, Robert Haas wrote: > >> On Tue, Jun 19, 2018 at 2:30 AM, Andres Freund wrote: > >> > This should be a PANIC imo. > >> > >> -1. As a developer, I would prefer

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-19 Thread Robert Haas
On Tue, Jun 19, 2018 at 1:01 PM, Andres Freund wrote: > On 2018-06-19 10:45:04 -0400, Robert Haas wrote: >> On Tue, Jun 19, 2018 at 2:30 AM, Andres Freund wrote: >> > This should be a PANIC imo. >> >> -1. As a developer, I would prefer PANIC. But as an end-user, I >> would much rather have repl

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-19 Thread Andres Freund
Hi, On 2018-06-19 10:45:04 -0400, Robert Haas wrote: > On Tue, Jun 19, 2018 at 2:30 AM, Andres Freund wrote: > > This should be a PANIC imo. > > -1. As a developer, I would prefer PANIC. But as an end-user, I > would much rather have replay continue (with possible problems) than > have it stop

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-19 Thread Robert Haas
On Tue, Jun 19, 2018 at 2:30 AM, Andres Freund wrote: > This should be a PANIC imo. -1. As a developer, I would prefer PANIC. But as an end-user, I would much rather have replay continue (with possible problems) than have it stopped cold in its tracks with absolutely nothing that I as the admin

Re: Excessive CPU usage in StandbyReleaseLocks()

2018-06-18 Thread Andres Freund
Hi, On 2018-06-19 17:43:42 +1200, Thomas Munro wrote: > The problem is that StandbyReleaseLocks() does a linear search of all > known AccessExclusiveLocks when a transaction ends. Luckily, since > v10 (commit 9b013dc2) that is skipped for transactions that haven't > taken any AELs and aren't usin