Re: A 2 phase commit weirdness

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: A 2 phase commit weirdness
Дата
Msg-id Pine.OSF.4.61.0505271712090.419436@kosh.hut.fi
обсуждение исходный текст
Ответ на Re: A 2 phase commit weirdness  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: A 2 phase commit weirdness  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, 26 May 2005, Tom Lane wrote:

> Alvaro Herrera <alvherre@surnet.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: foreign keys and RI triggers
Следующее
От: "Mark Cave-Ayland"
Дата:
Сообщение: Re: Cost of XLogInsert CRC calculations