On 04.03.2011 23:28, Kevin Grittner wrote:
> I wrote:
>
>> I think what we're protecting against is disk I/O at COMMIT time,
>> not transaction startup.
>
> One more thought on this -- on a properly configured server, this
> code should rarely be exercised unless there is a long-running READ
> WRITE transaction. The delay, if any, would be on the connection
> which is committing that long running transaction.
What worries me most is that the cleanup happens while
SerializableXactHashLock is held. It's probably not a big deal in
practice, but it seems safer and probably more readable too to do the
cleanup at checkpoint.
Here's what I had in mind. Can you review, and do you have something to
test this with?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
