Là một chức năng bị bỏ (hoặc thay đổi) vẫn có sẵn trong các giao dịch đã mở?

tôi đã tìm thấy

• PostgreSQL - Có phải TẠO CHỨC NĂNG và khóa CHỨC NĂNG DROP khi được sử dụng trong các giao dịch khác nhau không?

nhưng không có câu trả lời và không hoàn toàn giống với câu hỏi của tôi (mặc dù rất giống nhau).

Hãy nói tôi làm như sau:

1. Tạo một chức năng myfunc()
2. Bắt đầu giao dịch từ khách hàng A
3. Bắt đầu giao dịch từ khách hàng B
4. Trong giao dịch B, sử dụng "tạo hoặc thay thế chức năng" để sửa đổi định nghĩa về myfunc()
5. Cam kết giao dịch B
6. Gọi myfunc()từ giao dịch A

Điều gì xảy ra ở bước 6? Tôi có gọi hàm ban đầu như được định nghĩa trong bước 1 không? Hoặc hình thức sửa đổi từ bước 4 (cam kết ở bước 5)?

Và nếu chức năng bị bỏ ở bước 4 thay vì bị sửa đổi, bước 6 sẽ thất bại hay thành công? (Đây có thể là cùng một câu hỏi nhưng sửa đổi có thể hoạt động khác nhau.)

Tài liệu về điều này ở đâu?

Điều gì xảy ra ở bước 6?

Giao dịch A thấy định nghĩa cập nhật của chức năng myfunc()ngay lập tức. (Nhưng hãy xem tác dụng của bộ đệm bên dưới.)

Và nếu chức năng bị bỏ ở bước 4 thay vì bị sửa đổi, bước 6 sẽ thất bại hay thành công?

Nó sẽ thất bại. (Nhưng hãy xem tác dụng của bộ đệm bên dưới.)

Các lệnh DDL của Postgres hoàn toàn giao dịch. Mặc dù giao dịch B không cam kết, cả hai giao dịch sẽ tiếp tục thấy các phiên bản khác nhau của chức năng. Nhưng các giao dịch đồng thời không thấy các thay đổi cam kết trong danh mục hệ thống. Sẽ có vẻ rõ ràng ở mức cô lập mặc định READ COMMITTED. Nhưng bạn thậm chí không thể ngăn chặn điều này với các mức cô lập REPEATABLE READhoặc SERIALIZABLE.

Nếu bạn nên gọi hàm trong giao dịch A trước khi giao dịch B thực hiện thay đổi, bộ đệm cục bộ có thể can thiệp. Trong các thử nghiệm của tôi, một cuộc gọi nữa đã hoạt động với chức năng được lưu trong bộ nhớ cache (cũ) trước khi cuộc gọi tiếp theo nhận thức được sự thay đổi và được trả lời tương ứng.

Tôi không tìm thấy tài liệu về cách bộ đệm danh mục hệ thống hoạt động chính xác cho điều này (vẫn có thể tồn tại ở đâu đó). Tôi không tin rằng bit cuối cùng (thêm một cuộc gọi được trả lời từ bộ đệm) là hành vi tốt nhất có thể.

BTW, các bước của bạn 3. - 5. có thể giảm xuống chỉ còn 4., không có sự khác biệt. Các trình bao bọc giao dịch rõ ràng hoặc ẩn hoạt động như nhau:

3. Bắt đầu giao dịch từ khách hàng B
4. Trong giao dịch B, sử dụng "tạo hoặc thay thế chức năng" để sửa đổi định nghĩa của myfunc ()
5. Cam kết giao dịch B

Câu hỏi thú vị.

Từ một thử nghiệm nhỏ, có vẻ như các sửa đổi và xóa chức năng là giao dịch. Có nghĩa là - trong bất kỳ mức cô lập nào - khi giao dịch 2 sửa đổi hoặc xóa chức năng, giao dịch 1 không biết đến nó và vẫn sử dụng phiên bản cũ của chức năng.

Mọi thay đổi đối với chức năng chỉ hiển thị sau khi giao dịch được thực hiện và chỉ đối với các giao dịch bắt đầu sau cam kết đó. Mức cô lập là không liên quan, vì hàm được kiểm tra không đọc bất kỳ dữ liệu nào từ bất kỳ bảng nào.

-- Create Function
x=# create or replace function f() returns integer as
$$ select 1 ; $$ immutable language sql ;
CREATE FUNCTION

-- TRAN 1
x=# begin ;
BEGIN
x=# select * from f() ;
 f 
---
 1
(1 row)
                    -- TRAN 2
                    x=# begin ;
                    BEGIN
                    x=# drop function f () ;
                    DROP FUNCTION
                    x=# commit ;
                    COMMIT
-- TRAN 1
x=# select * from f() ;
 f 
---
 1
(1 row)
x=# commit ;
COMMIT

-- After COMMIT
x=# select * from f() ;
ERROR:  function f() does not exist
LINE 1: select * from f() ;
                      ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
x=# 

Trong một kịch bản hơi khác, nếu cả hai giao dịch đều cố gắng sửa đổi chức năng, thì chỉ có một giao dịch thành công và giao dịch kia bị chặn và sau đó thất bại nếu lần đầu tiên thực hiện.