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.
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 |