| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: scary patch contest |
| Date: | 2026-08-26 12:00:20 |
| Message-ID: | CAApHDvqBudqUpjckbbePwyQnfmCrEOj50pPOXnCR5H5AetAY3Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 26 Aug 2026 at 04:48, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I don't currently have a firm position on what we should do here. I
> think it's pretty clear that none of these were as robust at commit
> time as we would like, but that doesn't mean that they're still
> broken.
I don't envy the job of the RMT having to make these choices, but IMO
part of the controls for where to set the bar for the trigger point
for a revert should include the amount of available quality review and
discussion bandwidth that's available at the time when the bug is
discovered. It's easy for people removed from the problem to sit at
home and demand that everything gets done, but when cycles are
limited, something must be sacrificed. Sometimes that's free time, but
it's hard not to let quality slip when under stress and pressure.
I don't have anything to quantify it for the community as a whole, but
at least for me, I don't think I've ever had fewer free cycles. I
suspect that's the case for many of us. So I don't think that it's
unreasonable to set the revert bar a bit lower this year.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ilya Gladyshev | 2026-08-26 12:03:02 | [PATCH] Remove redundant path_nulls checks in setPathObject/Array |
| Previous Message | David Rowley | 2026-08-26 11:09:32 | Re: More partition pruning bugs with multi-column RANGE partitions |