On Tue, Feb 28, 2012 at 12:28 AM, Noah Misch <n...@leadboat.com> wrote: > On Mon, Feb 27, 2012 at 02:13:32PM +0200, Heikki Linnakangas wrote: >> On 23.02.2012 18:01, Alvaro Herrera wrote: >>> As far as complexity, yeah, it's a lot more complex now -- no question >>> about that. >> >> How about assigning a new, real, transaction id, to represent the group >> of transaction ids. The new transaction id would be treated as a >> subtransaction of the updater, and the xids of the lockers would be >> stored in the multixact-members slru. That way the multixact structures >> wouldn't need to survive a crash; you don't care about the shared >> lockers after a crash, and the xid of the updater would be safely stored >> as is in the xmax field. >> >> That way you wouldn't need to handle multixact wraparound, because we >> already handle xid wraparound, and you wouldn't need to make multixact >> slrus crash-safe. >> >> Not sure what the performance implications would be. You would use up >> xids more quickly, which would require more frequent anti-wraparound >> vacuuming. And if we just start using real xids as the key to >> multixact-offsets slru, we would need to extend that a lot more often. >> But I feel it would probably be acceptable. > > When a key locker arrives after the updater and creates this implicit > subtransaction of the updater, how might you arrange for the xid's clog status > to eventually get updated in accordance with the updater's outcome?
Somewhat off-topic, but just seen another bad case of FK lock contention. Thanks for working on this everybody. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
