準備/執行中3.2 Npgsql的

我使用的是3.2 Npgsql的，似乎是司機，現已自動準備語句。準備/執行中3.2 Npgsql的

我看到在PostgreSQL的日誌中的以下內容：

LOG: execute <unnamed>:SELECT * FROM database.update_item($1, $2, $3 , $4)

我可能是錯的，但是這不是在連接字符串啓動，我看不出之前的「準備」在日誌中調用。

我缺少什麼？

另外我在Npgsql之上使用Dapper 1.50.2來查詢數據庫。這還沒有在這個級別實現，但我看到GitHub上有一些關於這種功能的討論。

我使用的是READ提交的事務來更新數據庫中的一行。該行使用2個不同的語句更新兩次。

在pgadmin查詢窗口中逐個播放語句時，它可以正常工作。

當驅動程序通過execute執行語句時，第一條語句似乎將鎖定在記錄上，第二條語句掛起。

這裏是在查詢窗口中的查詢跑（運行到完成）：當由Npgsql的演奏

LOG: statement: BEGIN; 
LOG: statement: SET TRANSACTION ISOLATION LEVEL READ COMMITTED; 
LOG: statement: SELECT * FROM database.update_item(params...); 
LOG: statement: SELECT * from database.update_item(params...); 
LOG: statement: ROLLBACK;

PostgreSQL的日誌：：

BEGIN; 

SET TRANSACTION ISOLATION LEVEL READ COMMITTED; 

SELECT * FROM database.update_item(params...); 

SELECT * from database.update_item(params...); 

ROLLBACK;

相應PG日誌

LOG: statement: BEGIN 
LOG: statement: SET TRANSACTION ISOLATION LEVEL READ COMMITTED 
LOG: execute <unnamed>: select * from database.update_item(params...) 
LOG: execute <unnamed>: select * from database.update_item(params...) <-- hangs

任何幫助表示讚賞。

EDIT 1：

附加信息：update_item（）函數PLPGSQL與一個EXECUTE語句更新該行。

編輯2：

添加PG日誌查詢窗口。

來源

2017-03-14 Olivier MATROT

首先，Npgsql的自動準備功能是opt-in - 它沒有激活連接字符串。即使如此，在Npgsql準備好之前，需要多次執行相同的SQL（默認爲5）。有關更多詳細信息，請參閱the documentation。

關於你的僵局，你同時運行你的代碼？換句話說，你是否同時有多個事務，更新相同的行？如果是這樣，那麼這可能是預期的PostgreSQL行爲，並且與Npgsql無關。當您更新事務中的行時，這些行將被鎖定，直到事務被提交。通常的修復是以相同的順序更新行。 See the PostgreSQL documentation瞭解更多詳情。

來源

2017-03-14 11:22:20

怎麼樣的Npgsql的通過 '執行'？不，沒有併發交易。 –

除非我誤解了，這只是表示該語句尚未由Npgsql編寫。理解僵局和準備問題之間的關係有點困難（並且不應該出現） - 請確認無論準備情況如何，僵局都會發生？僵局總是會發生，還是偶爾發生？最後，一個完整的代碼示例（包括函數）將有助於重現此問題。 –

從pgadmin查詢窗口中不會發生死鎖，其中查詢逐個運行。有聲明登錄pglog。每次在同一連接上從Npgsql運行查詢時，都會發生這種情況。有記錄爲執行。那些只是事實。我同意你的看法，準備應該不會弄亂鎖定。我正在尋找線索。 –

準備/執行中3.2 Npgsql的

回答

相關問題