From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)surnet(dot)cl>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A 2 phase commit weirdness |
Date: | 2005-05-27 14:24:31 |
Message-ID: | Pine.OSF.4.61.0505271712090.419436@kosh.hut.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 26 May 2005, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)surnet(dot)cl> writes:
>> I'm wondering what should happen at prepare time so that "my own cache"
>> is correct.
>
> Good point. As far as the local caches are concerned, we probably have
> to make it look like the transaction rolled back. I think Heikki
> already had code in there to send the right inval messages when the
> prepared transaction ultimately commits ... but we'll have to check that
> that sequence does the right things ...
Looking at the sequence, at least the relcache init file stuff looks if
not broken at least a bit heavy-handed...
BTW: Is there a race condition in the relcache init file invalidation,
even without 2PC?
AtEOXact_Inval does basically this:
1. Unlink init file
2. Send inval messages
3. Unlink the init file again
Now consider this scenario:
backend A: Do updates that cause an init file invalidation
backend A: Commit begins
backend A: unlink init file
backend B starts and recreates init file
backend A: send inval message
backend C starts and reads the now stale init file
The window is admittedly very small, but it just caught my eye. Or am I
missing some lock etc?
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Cave-Ayland | 2005-05-27 15:01:00 | Re: Cost of XLogInsert CRC calculations |
Previous Message | Neil Conway | 2005-05-27 14:21:18 | Re: foreign keys and RI triggers |