postgres ALTER TABLE being blocked

Question

Im running Postgres 8.3 and I am having trouble running AN ALTER TABLE ADD COLUMN statement which seems to be blocked by an AccessShareLock when I run this query

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;

The table's name is dealer.

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

I also ran

SELECT * FROM pg_prepared_xacts    

That returned

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

The transaction id 154985751 looks similar to the virtualtransaction in the pg_locks table -1/154985751

I ran this command to view any processes that may be running queries on the database

ps axu | grep postgres | grep -v idle 

and have confirmed there are no other processes running queries on the database.

The log file shows this after the query has been run

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;

What could be causing the AccessShareLock on the dealer table? Im guessing it has something to do with the transaction 154985751 is there a way to terminate a transaction with using the virtual id?

Answer 1

You have a prepared transaction in place. Prepared transactions - those where PREPARE TRANSACTION but not COMMIT PREPARED or ROLLBACK PREPARED has been run - hold locks, just like normal running transactions do.

Prepared transactions may be used by XA transaction managers, JTA, etc, not necessarily directly by your app. Many queuing systems use them too. If you don't know what the transaction is and you commit it or roll it back you may disrupt something that is relying on two-phase commit.

---

If you are certain that you know what it is you can:

COMMIT PREPARED '131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM='

or

ROLLBACK PREPARED '131075_MS1hMzIwM2E3OmIwMjM6NTQxMGY0MzE6MWM1ZTg5OQ==_YTMyMDNhNzpiMDIzOjU0MTBmNDMxOjFjNWU4OWM='

depending on whether you wish to commit or abort the prepared xact.

You can't inspect the transaction to see what it did/does, you need to figure out what app/tool created it and why if you don't know what it is.

---

The identifier looks suspiciously like [number]_[base64]_[base64] so lets see what we can do with that:

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)

Hm, looks like ASCII or similar, lets see:

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)

Looks vaguely GUID/UUID-ish, with odd formatting and grouping.

Maybe those identifiers will help you figure out where the xact came from.

---

BTW, 8.3 is exceedingly obsolete. Plan your upgrade.