Re: pgsql: Fix a couple of bugs in MultiXactId freezing
От | Noah Misch |
---|---|
Тема | Re: pgsql: Fix a couple of bugs in MultiXactId freezing |
Дата | |
Msg-id | 20131203181438.GE1163520@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: pgsql: Fix a couple of bugs in MultiXactId freezing (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Re: pgsql: Fix a couple of bugs in MultiXactId freezing |
Список | pgsql-hackers |
On Tue, Dec 03, 2013 at 04:37:58PM +0100, Andres Freund wrote: > On 2013-12-03 10:29:54 -0500, Noah Misch wrote: > > Sorry, my original report was rather terse. I speak of the scenario exercised > > by the second permutation in that isolationtester spec. The multixact is > > later than VACUUM's cutoff_multi, so 9.3.1 does not freeze it at all. 9.3.2 > > does freeze it to InvalidTransactionId per the code I cited in my first > > response on this thread, which wrongly removes a key lock. > > That one is clear, I was only confused about the Assert() you > reported. But I think I've explained that elsewhere. > > I currently don't see fixing the errorneous freezing of lockers (not the > updater though) without changing the wal format or synchronously waiting > for all lockers to end. Which both see like a no-go? Not fixing it at all is the real no-go. We'd take both of those undesirables before just tolerating the lost locks in 9.3. The attached patch illustrates the approach I was describing earlier. It fixes the test case discussed above. I haven't verified that everything else in the system is ready for it, so this is just for illustration purposes. -- Noah Misch EnterpriseDB http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: