Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)
От | Peter Geoghegan |
---|---|
Тема | Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch) |
Дата | |
Msg-id | CAM3SWZTWVui+m0mYFa+jRyVwnA71t20zHLhXexUQp+TNZe7Emw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch) (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Problems with approach #2 to value locking (INSERT ... ON
CONFLICT UPDATE/IGNORE patch)
|
Список | pgsql-hackers |
On Sat, Jan 3, 2015 at 12:42 PM, Peter Geoghegan <pg@heroku.com> wrote: > There are probably additional factors that make the situation more > complicated than it is for the ON CONFLICT patch, but it's clear to me > that the mutual dependency that can be involved with two ordinary > exclusion constraint inserters is reason enough for those to deadlock. I looked at the code in more detail, and realized that there were old bugs in the exclusion constraint related modifications. I attach a delta patch that fixes them. This is a combined patch that is all that is needed to apply on top of v1.8.vallock2.tar.gz [1] to have all available bugfixes. This unbreaks my previous exclusion constraint test case, as far as it goes. I am still concerned about the risk of lock starvation/livelocks here. But I must admit, having stressed the patch with this latest fix, that it's possible that the real risks have been overestimated. Maybe this is in the same category as the way L&Y's algorithm could theoretically starve a session with a pagesplit that needs to move right indefinitely. It's a theoretical risk that turns out to not matter in practice, for reasons that lack a real theoretical justification beyond the fact that sustained very bad luck - a sustained "perfect storm" - is required for starvation to occur. OTOH, maybe my OS scheduler doesn't have the characteristic that provoke a the suspected bug. I really don't know, but I suppose that one or the other concurrent inserters will tend to win the race often enough - a draw may be a very rare thing. [1] http://www.postgresql.org/message-id/CAM3SWZRg_hTrOL-6_wfe6_d_UcUYc28JfaPsFh_tra76GkkdNw@mail.gmail.com -- Peter Geoghegan
Вложения
В списке pgsql-hackers по дате отправления: