Re: ALTER TABLE lock strength reduction patch is unsafe
От | Tom Lane |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | 14208.1308669155@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock strength reduction patch is unsafe (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: ALTER TABLE lock strength reduction patch is unsafe
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: > On Mon, Jun 20, 2011 at 10:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The ALTER TABLE patch >> has greatly expanded the scope of the issue, and that *is* a regression >> compared to prior releases. > I agree the scope for RELOID errors increased with my 9.1 patch. I'm > now happy with the locking patch (attached), which significantly > reduces the scope - back to the original error scope, in my testing. > I tried to solve both, but I think that's a step too far given the timing. > It seems likely that there will be objections to this patch. Yup, you're right. Having read this patch, I have absolutely zero confidence in it. It introduces some locks in random places, with no rhyme or reason that I can see. There is no reason to think that this is a complete solution, and considerable reason to think that it isn't (notably, the RELOID syscache is hardly the only one at risk). Worse, it's adding more locking in performance-critical places, which seems to me to severely degrade the argument for the original feature, namely that it was supposed to give us *less* locking. regards, tom lane
В списке pgsql-hackers по дате отправления: