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.