Jepsen, ParticleDB의 '완전한 ACID' 주장에 96가지 결함 폭로

소프트웨어에서 흥미로운 이분법을 알게 되었습니다:

어떤 소프트웨어는 전체 설계가 말이 되고 작동하지 않는 경우가 대개 국소적인 버그인 의미에서 '구성상 올바른' 소프트웨어입니다.

어떤 소프트웨어는 '구성상 올바르지 않은' 소프트웨어이며, 대개 운과 대부분 또는 모든 코드 경로에서 부정확성을 노출할 수 있는 부분을 조심스럽게 우회하는 조합으로 작동하는 경향이 있습니다. (AI는 우회 조치를 삽입할 관련 위치를 찾는 데 상당히 효과적일 수 있습니다.)

ParticleDB는 후자 범주인 것 같습니다. 많은 대규모 프로젝트에는 한 범주에 속하는 부분과 다른 범주에 속하는 부분이 있습니다.

덧붙여, 지난 하루 이틀 동안 저는 Linux 커널의 folio pinning 처리가 '구성상 올바르지 않은' 범주에 속하는 것 같다고 생각해 왔습니다. 좋은 시절이군요. 아니, 보안이나 우발적 손상 문제라고 믿을 만하게 특징지을 수 있는 고치기 어려운 버그를 발견한 것은 아닙니다[0]. 하지만 이는 대부분 운인 것 같습니다.

[0] 몇 달 전 Anthropic의 대규모 덤프에서도 발견된 버그를 다시 발견한 것 같고, 현재 수정 중입니다. 애플리케이션이 '고정된' io_uring I/O를 수행하거나 memfd에서 특정 유형의 iommu 기반 또는 아마도 RDMA를 수행한다면, 드물게 이를 접할 가능성이 있습니다. 재현기를 만들려고 애쓰지는 않았습니다.

> ParticleDB의 홈페이지는 ParticleDB가 TLA+ 증명으로 '형식적으로 증명되었다'고 광고했습니다. 그러나 우리의 협업 동안 어떤 TLA+ 명세도 이용 가능하지 않았습니다. 어떤 속성이 증명되었는지, 또는 그것이 구축된 ParticleDB를 설명했는지는 불분명합니다.

> 우리가 발견한 안전 오류의 심각성과 범위, 그리고 이를 생성한 프로세스를 고려하여, Jepsen은 사용자들이 ParticleDB의 추가 배포를 중단하고 가능한 한 빨리 다른 데이터베이스로 마이그레이션할 것을 권장합니다. 가능하다면 더 신뢰할 수 있는 소스에서 데이터베이스 상태를 확인하거나 재구축하는 것을 고려하십시오.

데이터베이스를 바이브코딩하면 이런 일이 생기는 것 같네요...

> 우리는 ParticleDB에서 96가지 문제를 제시합니다. 평범한 것(크래시, 교착 상태, 데이터 손실 등)부터 흥미로운 것(삭제할 수 없는 부분적으로 보이지 않는 행, WHERE 4 = 5, 왜곡된 형태로 다시 나타나는 삭제된 테이블, 혼란스러운 열, 정수가 되는 문자열 등)까지 다양합니다.

확실히 평소보다 심각해 보입니다(돌아보면 대부분의 데이터베이스는 총 10개 미만의 문제를 가지고 있고 대다수는 '경미한' 것 같습니다). AI를 위한 데이터베이스이므로 바이브코딩되었거나 그냥 새로운 것일까요? 그렇다 하더라도 새롭더라도 안정 릴리스에서 이렇게 많은 문제가 있을 것이라고는 예상하지 못했습니다

얼마나 형편없는지 정말 놀랍습니다. 바이브코딩된 데이터베이스라면 놀랄 일도 아니지만, 왜 스스로 어떤 테스트도 먼저 하지 않고 Kyle을 테스트에 고용했을까요?

> 문자열이 때때로 8비트 정수로 변했습니다 (#37)

드디어 eMudhra의 키에 무슨 일이 있었는지 알겠네요!

(죄송합니다. 정말 참을 수가 없었어요.)

"WHERE 4 = 5"가 행을 반환하는 것 같은 버그를 출시한다는 것만으로도 모든 것을 말해줍니다