On Tue, Dec 03, 2013 at 07:26:38PM +0100, Andres Freund wrote:
> On 2013-12-03 13:14:38 -0500, Noah Misch wrote:
> > On Tue, Dec 03, 2013 at 04:37:58PM +0100, Andres Freund wrote:
> > > 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.
>
> 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.
> > 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.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com