On 2013-12-03 13:49:49 -0500, Noah Misch wrote: > On Tue, Dec 03, 2013 at 07:26:38PM +0100, Andres Freund wrote: > > On 2013-12-03 13:14:38 -0500, Noah Misch wrote: > > > 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. > > > > I think it's changing the wal format then. > > I'd rather have an readily-verifiable fix that changes WAL format than a > tricky fix that avoids doing so. So, modulo not having seen the change, +1.
Well, who's going to write that then? I can write something up, but I really would not like not to be solely responsible for it. That means we cannot release 9.3 on schedule anyway, right? > > > 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. > > > > > That might be better than the current state because the potential damage > > from such not frozen locks would be to get "could not access status of > > transaction ..." errors (*). > > > > *: which already are possible because we do not check multis properly > > against OldestVisibleMXactId[] anymore. > > Separate issue. That patch adds to the ways we can end up with an extant > multixact referencing an locker XID no longer found it CLOG, but it doesn't > introduce that problem. Sure, that was an argument in favor of your idea, not against it ;). Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers