Di postgres apakah aman untuk (salah) menggunakan urutan sementara (sesi-lokal) sebagai urutan lokal transaksi?

Saya ingin memiliki counter yang akan saya reset ke 0 setiap kali transaksi baru dimulai. Saya ingin nilai penghitung itu digunakan di beberapa pemicu. Karena urutan sementara postgres adalah sesi lokal, saya dapat menggunakan satu sebagai penghitung hanya jika tidak ada kemungkinan 2 transaksi berjalan secara "paralel" di sesi yang sama. Apakah ini aman untuk diasumsikan di Postgres? (Apa yang ada dalam pikiran saya yang membuat saya merasa tidak yakin adalah situasi seperti transaksi otonom di Oracle. Dalam skenario itu, objek lokal sesi saya akan dibagikan oleh transaksi luar dan transaksi otonom dalam yang akan merusak lokalitas transaksi dari objek yang saya inginkan. .)

Saya tahu bahwa saya dapat menggunakan tabel TEMP dengan ON COMMIT DROP atau DELETE ROWS, tetapi saya ingin tahu apakah urutan temp sudah cukup, setidaknya di postgres.


person Paralife    schedule 06.12.2011    source sumber
comment
Jadi apa sebenarnya pertanyaan Anda? Apakah aman? tidak cukup spesifik. Apa yang ingin Anda capai?   -  person Erwin Brandstetter    schedule 07.12.2011
comment
Saya ingin tahu apakah objek lokal sesi dapat diakses oleh lebih dari 1 transaksi secara bersamaan dengan cara apa pun yang memungkinkan. Saya menjelaskan lebih rinci konteks pertanyaan saya. Maaf jika tidak jelas.   -  person Paralife    schedule 07.12.2011


Jawaban (1)


Saat ini PostgreSQL tidak memiliki dukungan untuk transaksi paralel atau otonom, jadi session == transaksi dan urutan sementara sesi-lokal hanya akan diakses oleh satu transaksi pada satu waktu.

Satu-satunya cara Anda dapat mensimulasikan transaksi otonom di Pg saat ini adalah dengan menggunakan dblink untuk membuat koneksi baru ke database. Karena itu juga membentuk sesi baru dan independen, Anda tidak perlu khawatir tentang apa pun dari dblink.

Saat ini aman (jika saya telah menafsirkan apa yang Anda inginkan dengan benar).

Dalam jangka panjang ada keinginan untuk memperkenalkan transaksi otonom sebagai bagian dari dukungan prosedur tersimpan yang sebenarnya. Sepertinya masih jauh, dan tidak jelas apakah transaksi otonom akan dapat melihat tabel dan urutan sementara yang dibuat oleh induknya. Anda harus menunggu dan melihat, dan bersiap untuk menyesuaikan pendekatan Anda, mungkin dengan menggunakan urutan sementara yang dinamai berdasarkan id transaksi saat ini (txid).

Anda dapat melakukannya sekarang jika Anda mau; gunakan fungsi txid_current() untuk mendapatkan ID transaksi saat ini.

Sunting: Tidak, txid tidak berubah di seluruh titik penyimpanan.

regress=> begin;
BEGIN
regress=> SELECT txid_current();
 txid_current 
--------------
       346947
(1 row)

regress=> savepoint test;
SAVEPOINT
regress=> SELECT txid_current();
 txid_current 
--------------
       346947
(1 row)

meskipun saya rasa itu bergantung pada detail implementasi.

person Craig Ringer    schedule 07.12.2011
comment
Saya memikirkan hal itu, tetapi saya tidak melakukannya karena saya mendapat kesan bahwa txid berubah dengan savepoint. Bukankah ini benar? - person Paralife; 07.12.2011
comment
@Paralife: Selain itu, beroperasi dengan pengidentifikasi dinamis mempersulit penggunaan fitur seperti default kolom atau SQL non-dinamis. - person Erwin Brandstetter; 07.12.2011
comment
txid tidak berubah di seluruh titik penyimpanan - lihat di atas. Jika Anda khawatir tentang hal itu, Anda dapat membuat pengidentifikasi dari txid dan CURRENT_TIMESTAMP (seperti yang diperbaiki pada awal txn). [Sunting: itu tidak masuk akal; txid masih akan berubah. Anda tidak dapat menggunakan hanya stempel waktu jika dua txns dimulai pada waktu yang sama hingga resolusi pengatur waktu. Ugh. Andalkan saja txid untuk tidak berubah, dan uji pemutakhiran dengan baik!] Menurut saya ini tidak akan terlalu bagus, tetapi Anda dapat membungkusnya dalam fungsi SQL sederhana untuk membuatnya lebih mudah digunakan secara default dan non-dinamis SQL seperti yang Erwin sebutkan sebagai perhatian. - person Craig Ringer; 09.12.2011