Re: segfault in HEAD when too many nested functions call

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
Subject: Re: segfault in HEAD when too many nested functions call
Date: 2017-08-01 04:46:50
Message-ID: 20170801044650.GB2650302@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 28, 2017 at 02:42:06PM -0400, Robert Haas wrote:
> On Fri, Jul 28, 2017 at 12:29 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > Your colleagues achieve compliance despite uncertainty; for inspiration, I
> > recommend examining Alvaro's status updates as examples of this. The policy
> > currently governs your open items even if you disagree with it.

Thanks for resolving this open item.

> I emphatically agree with that. If the RMT is to accomplish its
> purpose, it must be able to exert authority even when an individual
> contributor doesn't like the decisions it makes.
>
> On the other hand, nothing in the open item policy the current RMT has
> adopted prohibits you from using judgement about when and how
> vigorously to enforce that policy in any particular case, and I would
> encourage you to do so.

I understand. When it comes to open item regulation, the aspects that keep me
up at night are completeness and fairness. Minimizing list traffic about
non-compliant open items is third priority at best. Furthermore, it takes an
expensive and subjective calculation to determine whether a policy-violating
open item is progressing well. I will keep an eye out for minor policy
violations that I can ignore cheaply and fairly.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2017-08-01 05:06:11 Re: Freeze on Cygwin w/ concurrency
Previous Message Tokuda, Takashi 2017-08-01 04:45:41 Improve the performance of the standby server when dropping tables on the primary server