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
