Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch |
Дата | |
Msg-id | 19748.1170969025@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [PATCHES] [pgsql-patches] Phantom Command IDs,
updated patch
|
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> writes: > The way combo cid is supposed to work is that you are deleting a row > created in your same transaction by a previous command id, so you look > in the combo cid array to see if a match for that pair exists --- if > not, you create a new entry and put the two cids on it. > So, with the combo lock cid, you do the same process, and lookups of who > holds the lock looks at the cid combo, and if the second subtransaction > was aborted, the first one is the lock holder. If you again lock the > row, you create a new combo cid and use the original cid there because > the second cid was aborted. No, because no process other than the originator can see the combo-cid data structure, and for locking situations you really need other backends to be able to know whether the tuple is locked and how. But I think my proposal of extending MultiXact would fix it; please look at that. regards, tom lane
В списке pgsql-hackers по дате отправления: