From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: foreign key locks, 2nd attempt |
Date: | 2012-02-28 07:55:31 |
Message-ID: | CA+U5nMLLdrgV-co4H5qsEtRHN+rvBUc-wGdFynHSGLwrbUuj8w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 28, 2012 at 12:28 AM, Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2012-02-28 08:04:44 | Re: Speed dblink using alternate libpq tuple storage |
Previous Message | Andrea Suisani | 2012-02-28 07:54:40 | Re: swapcache-style cache? |