確認問題：承認後に誰かが先に変更した

배치의 첫 행 취소는 성공했지만 두 번째 행의 버전이 승인과 다릅니다. 필요한 결과는?

• 첫 행을 남기고 두 번째 행만 건너뛰어 전체 성공으로 보고한다
• 현재 버전으로 두 번째 대상을 고쳐 승인 없이 계속 적용한다
• 바깥 트랜잭션을 롤백하여 첫 행의 취소도 남기지 않는다
• 오류 메시지만 반환하고 첫 행이 남았는지는 확인하지 않는다

승인 버전을 SELECT로 비교한 다음 ID만 조건으로 UPDATE하면 어떤 틈이 생기나요?

• SELECT가 자동으로 모든 고객의 테이블을 영구 잠근다
• UPDATE가 앞 SELECT의 결과를 항상 자동 재사용한다
• RETURNING이 없는 조회만 PostgreSQL에서 실행될 수 있다
• 두 문장 사이 다른 변경이 들어와 오래된 승인으로 덮을 수 있다

Read Committed에서 UPDATE가 다른 작업자의 행 잠금을 기다렸고, 앞 작업자가 revision을 올려 커밋했습니다. 기대 동작은?

• 갱신된 행에 WHERE를 다시 대조하여 오래된 revision 조건은 실패한다
• 처음 관측한 revision만 사용하여 잠금 뒤에도 무조건 변경한다
• 기다린 시간이 길면 승인 목록의 revision을 자동 증가시킨다
• 앞 작업자의 커밋을 취소하고 이전 버전의 행을 복원한다

감사와 변경을 커밋한 직후 클라이언트가 종료돼 성공 응답을 잃었습니다. 같은 ID·같은 승인 내용으로 다시 실행하면?

• 변경을 한 번 더 실행하고 revision을 다시 증가시킨다
• 확정 영수증을 확인하고 새 효과 없이 False를 반환한다
• 기존 영수증을 지우고 새로운 변경 ID로 강제 재시도한다
• 현재 상태가 cancelled이므로 성공 여부를 영원히 알 수 없다

영수증에는 주문 1·2가 있지만 현재 주문 2는 없어지고 주문 6이 같은 값으로 생겼습니다. reconcile의 판단은?

• 현재 총 건수가 같으므로 두 주문이 모두 일치한다고 본다
• 주문 6을 주문 2로 바꿔 영수증과 현재 상태를 강제로 맞춘다
• 원래 주문 2를 누락으로 표시하고 현재 데이터는 바꾸지 않는다
• 영수증에서 주문 2를 지워 이후 대조가 통과하게 만든다

기존 실습 DB는 fsync와 full_page_writes가 꺼져 있습니다. 클라이언트 강제 종료 시험의 통과로 말할 수 있는 범위는?

• 운영 서버의 전원 차단 뒤에도 모든 커밋이 보존된다는 보장
• 저장장치가 손상돼도 백업 없이 전체 데이터를 복원한다는 보장
• 여러 호스트의 장애와 네트워크 분할에서도 합의가 유지된다는 보장
• 살아 있는 DB 서버에서 연결 종료와 재접속의 결과를 확인한 사실