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,
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo