Question

I am currently trying to maintain a postgres database of player information when I’ve encountered an issue with one of our players. The player came to us saying that he could not load his character into the game world. I did a small SELECT statement to pull up the player information with no problems. However, when they try to use a character then we update a field in the row that says that the player character is active. However we noticed that we couldn’t run an update or a delete statement on that row. Every other row in the table gets modified without any issues.

On of our DB admins thought that it was a lock that was applied on that row, but after further investigation with see nothing that could be locking that row.

Any advice or suggestions is greatly appreciated.

Answer 1

It certainly sounds like a lock.

The “big hammer” approach is bouncing (stoping/starting) your database to kill any running queries.

The “scalpel” approach is to run show full processlist; and try to find a query that’s running that might have created a lock. Note that the query itself might not lock the row, but an earlier query in the same transaction might have locked it. Any long-running query is a suspect.

EDIT

I have found an issue in postgres that keeps the lock even after a restart. Here’s how you find and fix it:

Run this query:

select * from pg_prepared_xacts

Here’s the doc for this system view

If there are any rows, it means there are orphaned/dangling transactions, which can hold locks even after restarting postgres.

To kill them, for every row get the gid (a long UUID), and execute this:

 ROLLBACK PREPARED '<paste gid here>'

That should clean things up.

If you are on a *nix platform, you can run this single command that will do the lot:

psql -U postgres mydatabase -c "select * from pg_prepared_xacts" | grep -v transaction | grep \| | awk '{print $3}' | xargs -I % psql -U postgres mydatabase -c "ROLLBACK PREPARED '%'"