I did a little AI-assisted bug-hunting in Postgres this summer in between jobs, and the haul was staggering. Multiple serialization anomalies (eg [0] [1] [2]), foreign key integrity issues ([3] [4]), planner correctness bugs such as [5]. Various CVE-worthy vulnerabilities. An unfixable timezone bug [6]. The list got so long that I had to triage what I even had time to report, and settled for a dozen or two out of hundreds of candidates. Now imagine the entire world doing this.

[0] Write skew observed under serializable isolation: https://www.postgresql.org/message-id/flat/CA+COZaBo+ZpKgMvx...

[1] Serializable anomaly: duplicate primary keys: https://www.postgresql.org/message-id/flat/CA+COZaBOiiRPmEfX...

[2] SERIALIZABLE can commit write skew after SSI summarization: https://www.postgresql.org/message-id/flat/CA+COZaCtK=UQbeQw...

[3] Fix temporal foreign key validation of pre-existing rows https://www.postgresql.org/message-id/flat/CA+COZaChq_ukm2o7...

[4] Lost lock during toasting allows FK violation https://www.postgresql.org/message-id/flat/CA+COZaC-2-GQabq+...

[5] Partition pruning can incorrectly exclude a RANGE default partition https://www.postgresql.org/message-id/flat/CA+COZaDXrfTaBjLE...

[6] timestamp vs. timestamptz comparisons inconsistently ordered under DST : https://www.postgresql.org/message-id/flat/c22286ad6268347c6...

▲

tibbar 34 minutes ago | parent | next [-]

By the way, Robert and the other maintainers are incredible to interact with. There are so many reports to triage and bugs to fix, but they're unflaggingly polite and quite generous with their time. I don't know of another community like it.

▲

rogerrogerr 3 hours ago | parent | prev | next [-]

> unfixable timezone bug

Very curious about the details and why it’s unfixable. Is it just because timezones are such a mess it’s logically impossible to satisfy every constraint?

▲

tibbar 2 hours ago | parent | next [-]

I will add more example links in the top-level comment, but here is the thread for that bug. [0]. tl;dr timestamp vs timestamptz comparisons aren't consistently ordered in a pathological edge case, which means that index scans can return the wrong answer. There's no way to fix it without either redefining the operators in a surprising way or disabling index scans in this case.

[0] https://www.postgresql.org/message-id/flat/c22286ad6268347c6...

	▲	paulryanrogers an hour ago \| parent [-]
		OT: Crazy that TZ-less are default in so many RDBMS. TZ included should be the default, and no-TZ opt in like TIMESTAMP NO TIME ZONE.

▲

2 hours ago | parent | prev [-]

[deleted]

▲

anoojb 2 hours ago | parent | prev | next [-]

i assume the magnitude of impact for a bunch of [now] glaring holes in popular software is unknowable.

question is, how long do you think this persists before there's only a long tail of minor exploits left?

▲

codebje 2 hours ago | parent [-]

I am pretty sure we have always been able to add holes faster than we can find them and fill them, and that this has not changed with the advent of faster hole finding tools that are also faster hole producing tools.

	▲	jimbokun an hour ago \| parent [-]
		It feels like we need AI methods to write provably correct code, along with a way for AI to automatically translate existing code into corresponding provably correct code. (And hope performance stays in the same ballpark as the old code.)

▲

jimbokun an hour ago | parent | prev [-]

[flagged]