Re: a very significant fraction of the buildfarm is now pink

From: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: a very significant fraction of the buildfarm is now pink
Date: 2025-02-24 12:27:02
Message-ID: 5abac84e-fc78-459a-a191-13efeb58c161@tantorlabs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Regarding the patch push, I am not a committer, but perhaps my
perspective might be interesting. When I noticed late on Friday evening
that the tests had failed, I was quite anxious about the situation,
thinking I would need to fix it right away. However, Robert committed
the fix before that.

In general, when someone commits in any project, I believe the scale of
the commit should be taken into account. In the case of postgres, if the
commit changes code in critical areas like the planner, WAL, or some
API, or involves large code changes, it’s important to be prepared to
fix any issues that may arise. However, when changes are more minor—such
as documentation, renaming something, or small refactors—committing late
on a Friday may be less of a concern.

In other words, the larger the changes or the more vulnerable the areas
of the code, the more one should be prepared for potential issues. But
how to determine this boundary in postgres, I am not sure. I am
confident that you will have a much better sense and experience of how
to handle it.

--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rahila Syed 2025-02-24 12:46:45 Re: Enhancing Memory Context Statistics Reporting
Previous Message Andrei Lepikhov 2025-02-24 12:22:35 Re: Removing unneeded self joins