Inkonsistensi dalam pembacaan berulang

http://www.postgresql.org/docs/9.2/static/transaction-iso.html

Mode Baca Berulang memberikan jaminan ketat bahwa setiap transaksi melihat tampilan database yang sepenuhnya stabil. Namun, pandangan ini tidak harus selalu konsisten dengan beberapa serial (satu per satu) eksekusi transaksi bersamaan dari tingkat yang sama. Misalnya, bahkan transaksi hanya baca pada level ini dapat melihat catatan kontrol diperbarui untuk menunjukkan bahwa batch telah selesai tetapi tidak melihat salah satu catatan detail yang secara logis bagian dari batch karena membaca revisi sebelumnya dari catatan kontrol . Upaya untuk menegakkan aturan bisnis dengan transaksi yang berjalan pada tingkat isolasi ini tidak akan berfungsi dengan benar tanpa menggunakan kunci eksplisit secara cermat untuk memblokir transaksi yang bertentangan.

Bukankah itu membaca hantu, yang tidak mungkin dalam mode baca berulang?

Dokumentasi mengatakan bahwa kueri dalam transaksi baca berulang melihat snapshot pada awal transaksi, lalu bagaimana mungkin bagi permintaan untuk membaca data yang tidak konsisten?

Inilah bacaan saya tentang bagian itu. Saya akui itu membingungkan.

Misalkan saya punya dua tabel:

CREATE TABLE batch (
   id serial not null unique,
   control_code text primary key,
   date_posted date not null default now()
);

CREATE TABLE details (
   batch_id int not null references batch(id),
   description text,
   primary key(batch_id, description)
);

Sekarang, misalkan kita menyisipkan catatan batch dan detail dalam transaksi yang berbeda. Sesi 1 menyisipkan batch dan mulai memasukkan detail tetapi sebelum selesai, sesi 2 dimulai. Sesi 2 dapat melihat info tajuk kumpulan, tetapi tidak menunggu komit perincian untuk memberi tahu pengguna bahwa tidak ada catatan yang ditemukan. Sekarang jika kumpulan dan detail Anda seluruhnya dalam transaksi yang sama maka ini tidak pernah menjadi masalah.

ini akan berbeda dari serializable di mana Anda akan menunggu untuk memasukkan sebelumnya untuk menyelesaikan dan melakukan atau rollback sebelum menentukan apakah akan memberi tahu pengguna bahwa tidak ada baris yang ditemukan.

Ada dokumen dalam PostgreSQL Wiki yang menunjukkan beberapa masalah yang dapat terjadi dengan kombinasi transaksi tertentu pada tingkat isolasi transaksi REPEATABLE READ, dan bagaimana mereka dihindari pada tingkat isolasi transaksi SERIALIZABLE yang dimulai dengan PostgreSQL versi 9.1.

Ini juga termasuk contoh tentang bagaimana mungkin untuk transaksi READ-ONLY tingkat REPEATABLE READ-ONLY untuk membaca data yang tidak konsisten.

Phantom reads (pastikan untuk tidak membingungkan ini dengan reads non-repeatable) dimungkinkan pada level isolasi "Repeatable read" ... pada prinsipnya. Tetapi perilaku de-facto Postgresql ketika Anda memilih "Repeatable read" lebih kuat dari standar, (hampir merupakan isolasi "Serializable"), sehingga, pada kenyataannya Anda tidak akan memiliki phantom yang dibaca. Docs :

Ketika Anda memilih level Read Uncommitted, Anda benar-benar mendapatkan Read Committed, dan phantom read tidak mungkin dalam implementasi PostgreSQL dari Repeatable Read , sehingga level isolasi yang sebenarnya mungkin lebih ketat daripada yang Anda pilih.

Sekarang, bagaimana dengan peringatan itu "pandangan ini tidak selalu harus konsisten dengan beberapa serial (satu per satu) eksekusi transaksi bersamaan dari tingkat yang sama"? Saya pikir (saya tidak yakin) itu berarti bahwa itu berarti snapshot "dari luar" (ditetapkan pada awal transaksi) pada akhirnya dapat menyertakan baris dari transaksi lain tetapi gagal untuk memasukkan beberapa baris lain dari transaksi yang sama.