postgres ALTER TABLE被阻止

Question

我正在運行Postgres 8.3，但在運行ALTER TABLE ADD COLUMN語句時遇到問題，當我運行此查詢時，該語句似乎被AccessShareLock阻止

SELECT t.relname,l.locktype,page,virtualtransaction,pid,mode,granted FROM pg_locks l, pg_stat_all_tables t WHERE l.relation=t.relid ORDER BY relation asc;

該表的名稱是經銷商。

    relname      | locktype | page | virtualtransaction |  pid  |        mode         | granted
dealer           | relation |      | 2/40               | 12719 | AccessExclusiveLock | f
dealer           | relation |      | -1/154985751       |       | AccessShareLock     | t

我也跑了

SELECT * FROM pg_prepared_xacts    

那回來了

transaction |                                             gid                                              |           prepared            |  owner   |      database      
  154985751 | 131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM= | 2014-09-19 08:01:49.650957+10 | user     | database

事務ID 154985751看起來類似於pg_locks表-1/154985751中的virtualtransaction

我運行了此命令以查看可能正在數據庫上運行查詢的所有進程

ps axu | grep postgres | grep -v idle 

並確認沒有其他進程在數據庫上運行查詢。

查詢運行后，日志文件顯示此內容

2014-11-14 17:25:00.794 EST (pid: 12719) LOG:  statement: BEGIN;
2014-11-14 17:25:00.794 EST (pid: 12719) LOG:  statement: ALTER TABLE dealer ADD bullet1 varchar;
2014-11-14 17:25:01.795 EST (pid: 12719) LOG:  process 12719 still waiting for AccessExclusiveLock on relation 2321398 of database 2321293 after 1000.133 ms
2014-11-14 17:25:01.795 EST (pid: 12719) STATEMENT:  ALTER TABLE dealer ADD bullet1 varchar;

是什么原因導致發牌人桌上的AccessShareLock？ 我猜測它與事務有關154985751是否可以使用虛擬ID終止事務？

Answer 1

您已准備好交易。 准備的事務-已運行“ COMMIT PREPARED PREPARE TRANSACTION但未執行“ COMMIT PREPARED或“ ROLLBACK PREPARED事務-保持鎖定，就像正常運行的事務一樣。

XA事務管理器，JTA等可以使用預准備的事務，而您的應用不必直接使用。 許多排隊系統也使用它們。 如果您不知道事務是什么，然后提交或回滾它，則可能會破壞依賴於兩階段提交的事務。

---

如果您確定自己知道這是什么，則可以：

COMMIT PREPARED '131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM='

要么

ROLLBACK PREPARED '131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM='

取決於您是要提交還是中止准備好的xact。

您無法檢查事務以查看其執行的操作，您需要弄清楚是什么應用程序/工具創建了它，以及為什么不知道它是什么。

---

標識符看起來像[number]_[base64]_[base64]一樣可疑，因此讓我們看看該怎么做：

postgres=> SELECT decode((string_to_array('131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM=','_'))[2], 'base64');
                              decode                              
------------------------------------------------------------------
 \x312d613332303361373a623032333a35343130663433313a31633565383939
(1 row)

postgres=> SELECT decode((string_to_array('131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM=','_'))[3], 'base64');
                            decode                            
--------------------------------------------------------------
 \x613332303361373a623032333a35343130663433313a31633565383963
(1 row)

嗯，看起來像ASCII或類似的東西，讓我們看看：

postgres=> SELECT convert_from(decode((string_to_array('131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM=','_'))[2], 'base64'), 'utfpostgres=> SELECT convert_from(decode((string_to_array('131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM=','_'))[2], 'base64'), 'utf-8');
          convert_from           
---------------------------------
 1-a3203a7:b023:5410f431:1c5e899
(1 row)

postgres=> SELECT convert_from(decode((string_to_array('131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM=','_'))[3], 'base64'), 'utf-8');
         convert_from          
-------------------------------
 a3203a7:b023:5410f431:1c5e89c
(1 row)

看起來含糊不清GUID / UUID-ish，帶有奇數格式和分組。

也許這些標識符可以幫助您確定xact的來源。

---

順便說一句，8.3已經過時了。 計划升級。