On Tue, Nov 15, 2011 at 10:55:49AM -0600, Kevin Grittner wrote: > And I would be > surprised if some creative thinking didn't yield a far better FL > scheme for SSI than we can manage with existing LW locks.
One place I could see it being useful is for SerializableFinishedListLock, which protects the queue of committed sxacts that can't yet be cleaned up. When committing a transaction, it gets added to the list, and then scans the queue to find and clean up any sxacts that are no longer needed. If there's contention, we don't need multiple backends doing that scan; it's enough for one to complete it on everybody's behalf. I haven't thought it through, but it may also help with the other contention bottleneck on that lock: that every transaction needs to add itself to the cleanup list when it commits. Mostly unrelatedly, the other thing that's looking like it would be really useful would be some support for atomic integer operations. This would be useful for some SSI things like writableSxactCount, and some things elsewhere like the strong lock count in the regular lock manager. I've been toying with the idea of creating an AtomicInteger type with a few operations like increment-and-get, compare-and-set, swap, etc. This would be implemented using the appropriate hardware operations on platforms that support them (x86_64, perhaps others) and fall back on a spinlock implementation on other platforms. I'll probably give it a try and see what it looks like, but if anyone has any thoughts, let me know. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
