Tom Lane wrote:
Unfortunately, there isn't any pre-existing lock that will serve. A transaction that is between XLogInsert'ing its COMMIT record and updating the shared pg_clog data area does not hold any lock that could be used to prevent a checkpoint from starting. (Or it didn't until yesterday's patch, anyway.)
I looked briefly at reorganizing the existing code so that we'd do the COMMIT XLogInsert while we're holding lock on the shared pg_clog data, which would solve the problem without adding any new lock acquisition. But this seemed extremely messy to do. Also it would be optimizing transaction commit at the cost of pessimizing other uses of pg_clog, which might have to wait longer to get at the shared data. Adding the new lock has the advantage that we can be sure it's not blocking anything we don't want it to block.
Thanks for thinking about the problem though ...
You are welcome.
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
