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
|
Список | 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 по дате отправления: