From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Adding null patch entry to cfbot/CommitFest |
Date: | 2025-05-20 03:11:33 |
Message-ID: | 605772.1747710693@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Monday, May 19, 2025, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>> I have observed cases where a cfbot entry fails without clear reason
>> [1]. Even if the patch just modifies comments, it has failed in some
>> cfbot test. In this case we could easily guess that master branch
>> might have problems at the time when the tests performed.
> I too made this realization while reviewing the application. I concur it
> is something that we should try and mitigate. Sending a canary patch
> through once-a-day, or on any fixed time period, doesn’t quite seem
> sufficient.
Yeah, I'm afraid that won't do much except eat valuable cycles.
IME the real problem with the CI tests is that the CI infrastructure
itself is not very stable, and intermittently fails tests for reasons
having little to do with the tested patch *or* the state of the master
branch. If there is a problem in master, we typically know it because
the buildfarm is also unhappy, so I'm not clear on what a null patch
in the queue would add.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-05-20 03:12:36 | Re: Add comment explaining why queryid is int64 in pg_stat_statements |
Previous Message | shveta malik | 2025-05-20 03:08:39 | Re: Conflict detection for update_deleted in logical replication |