| From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Michael Malis <malis(at)pgrust(dot)com>, pgsql-hackers(at)postgresql(dot)org, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Subject: | Re: Preferred way to submit a very large batch of bugs? |
| Date: | 2026-11-05 05:07:39 |
| Message-ID: | CABPTF7Xw-wEzdQLRiTtvp3YfVLAD1ZjEU+_zwMjSH=+E2HR0kA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, Nov 5, 2026 at 3:18 AM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi Michael,
>
> I have been sending AI-found bugs this year. Here is what worked.
>
> Before I send one, I have Claude search the archives and the commit
> log for it. There are some very good postgres mcp server such as
> https://pg.ddx.io/ is good for that use case I also have skills for this
> and am happy to share them.
> I reproduce every bug by hand, which catches false positives. Then I
> ask what kind of user/workload would hit it. A superuser-only case on a
> platform you have never heard of is probably not worth sending.
> A SELECT * from table that returns wrong results is a big deal.
>
> I review every fix myself. I asked Claude to push it to a private GitHub repo,
> so I get a diff view and can ask about any line and review it.
>
> One thing I found is that the LLM often fixes the symptom, not the root cause.
It seems somewhat helpful to instruct it to identify the root cause
before suggesting any fixing strategies.
> I am sure I have made some noise too. I am happy to follow whatever
> AI policy the community ends up with.
The current mailing list and commitfest seems unable to scale up well
with the growing numbers of bug reports. We don't have an issue ticket
system for tracking those bugs and there're no strict owners for them
as well except for the reported bugs of the newly-minted features.
Submitting a huge amount of bug reports at once seems like it would
blow up the whole thing. Therefore, besides the suggestions given by
other hackers, I am wondering whether it's helpful to build a
temporary site or use existing tools to track those bugs after
filtering, auditing and grouping them. This seems able to meet future
needs to some extent as well. That said, not sure about the degree of
that demand since there's a likely ceiling to the current growth of
bug reports -- the existing stock of them would be exhausted one day
after massive hunting and the bar of getting into the core has raised
because new features are already under heavy-scrutiny by LLMs, which
are quite good at catching edge cases. Another complementary tool that
seems helpful is something like the sashiko review system from the
linux community [1].
[1] https://github.com/sashiko-dev/sashiko
--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2026-11-05 05:10:03 | proposal - log queries where plan was changed due effective_cache_size |
| Previous Message | Tender Wang | 2026-11-05 05:01:50 | MERGE fails with RETURNING when an excluded inheritance parent has an extra-column child |