rseq가 대안으로 제시되긴 했지만, Linux 전용 코드를 도입해야 한다는 점에서 크로스 플랫폼을 고려해야 하는 오픈소스 프로젝트 입장에서는 쉽게 받아들이기 어려운 제안일 것 같습니다.

메이저 버전업에서 동작 변경이 생기는 건 이해할 수 있지만, 결과적으로 50% 성능 하락이 발생했다면 인프라를 운영하는 입장에서는 커널 업그레이드 자체를 조심스럽게 바라볼 수밖에 없을 것 같네요.

워우 출장 중에 댓글 달고 호텔 와서 보니 세 분이나 의견을 주셨네요. 감사합니다.

말씀주신 관점도 저는 충분히 이해합니다만, 저는 그래도 이걸 postgres 측의 tech debt로 보고 있어서, 결국 postgres가 결자해지 해야 하는 건으로 보고 있습니다. (당장 성능을 위해 hack 등을 써오다가 피본 경험은 spectre로 충분한 듯하여...)
결국 이 건은 당분간 두고 보아야 할 듯합니다.

좋은 하루 보내세요. :)

동의합니다. 인텔의 리눅스 엔지니어들이 퇴직하는 소식들을 종종 접하는데 기존 behavior들을 계속 방치하기엔 언젠간 윈도우 같이 될겁니다 o,o..

이미 해당 구현은 최적의 성능을 위해 플랫폼 별 전용 어셈블리 코드가 가득한 부분이라
특정 플랫폼 전용 코드가 추가된다는 것 때문에 못한다는 건 이유가 될 수 없을 것 같네요.
(제미나이에게 물어보고 요약 했습니다.)

코드 봤는데 그정도로 어셈블리 코드가 가득한 함수도 아니고, 어셈블리 코드가 가득하다는 것이 특정 플랫폼 전용 코드를 추가해도 문제가 된다는 것이 아니라고 생각됩니다. 어셈블리 코드라고 하는 게 아토믹 연산 함수 (GCC의 빌트인 atomic 함수들)말하는 것 같은데 함수 안만 보면 리눅스만 특별하게 코드를 추가할 수는 없는데요.