On 23.02.2012 18:01, Alvaro Herrera wrote:
>
> Excerpts from Tom Lane's message of jue feb 23 12:28:20 -0300 2012:
>>
>> Alvaro Herrera<alvherre@commandprompt.com> writes:
>>> Sure. The problem is that we are allowing updated rows to be locked (and
>>> locked rows to be updated). This means that we need to store extended
>>> Xmax information in tuples that goes beyond mere locks, which is what we
>>> were doing previously -- they may now have locks and updates simultaneously.
>>
>>> (In the previous code, a multixact never meant an update, it always
>>> signified only shared locks. After a crash, all backends that could
>>> have been holding locks must necessarily be gone, so the multixact info
>>> is not interesting and can be treated like the tuple is simply live.)
>>
>> Ugh. I had not been paying attention to what you were doing in this
>> patch, and now that I read this I wish I had objected earlier.
>
> Uhm, yeah, a lot earlier -- I initially blogged about this in August
> last year:
> http://www.commandprompt.com/blogs/alvaro_herrera/2011/08/fixing_foreign_key_deadlocks_part_three/
>
> and in several posts in pgsql-hackers.
>
>> This
>> seems like a horrid mess that's going to be unsustainable both from a
>> complexity and a performance standpoint. The only reason multixacts
>> were tolerable at all was that they had only one semantics. Changing
>> it so that maybe a multixact represents an actual updater and maybe
>> it doesn't is not sane.
>
> 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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com