Re: 'tuple concurrently updated' error for alter role ... set
От | Tom Lane |
---|---|
Тема | Re: 'tuple concurrently updated' error for alter role ... set |
Дата | |
Msg-id | 11572.1305239328@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 'tuple concurrently updated' error for alter role ... set (Alexey Klyukin <alexk@commandprompt.com>) |
Ответы |
Re: 'tuple concurrently updated' error for alter role ... set
Re: 'tuple concurrently updated' error for alter role ... set |
Список | pgsql-hackers |
Alexey Klyukin <alexk@commandprompt.com> writes: > After digging in the code I've found that a RowExclusiveLock is acquired on a pg_db_role_setting table in AlterSetting().While the name of the locks suggests that it should conflict with itself, it doesn't. After I've replacedthe lock in question with ShareUpdateExclusiveLock, the problem disappeared. Attached is the simple patch with thesechanges. We're not likely to do that, first because it's randomly different from the handling of every other system catalog update, and second because it would serialize all updates on this catalog, and probably create deadlock cases that don't exist now. (BTW, as the patch is given I'd expect it to still fail, though perhaps with lower probability than before. For this to actually stop all such cases, you'd have to hold the lock till commit, which greatly increases the risks of deadlock.) I see no particular reason why conflicting updates like those *shouldn't* be expected to fail occasionally. regards, tom lane
В списке pgsql-hackers по дате отправления: