On Fri, Jun 8, 2018 at 1:08 PM Andres Freund <andres@anarazel.de> wrote:
On 2018-06-08 12:38:03 -0500, Jeremy Finzel wrote: > On Tue, Jun 5, 2018 at 8:42 PM, Alexandre Arruda <adaldeia@gmail.com> wrote: > > > Em seg, 28 de mai de 2018 às 16:44, Andres Freund <andres@anarazel.de> > > escreveu: > > > > > > Hi, > > > > > > I think I found the bug, and am about to post a fix for it belo > > > https://postgr.es/m/20180525203736.crkbg36muzxrjj5e@alap3.anarazel.de. > > > > > > Greetings, > > > > > > Andres Freund > > > > Hi Andres, > > > > In end of April we did a complete dump/reload in database to version 10.3. > > Today, the problem returns: > > > > production=# vacuum verbose co27t; > > INFO: vacuuming "public.co27t" > > ERROR: found multixact 81704071 from before relminmxid 107665371 > > production=# vacuum full verbose co27t; > > INFO: vacuuming "public.co27t" > > ERROR: found multixact 105476076 from before relminmxid 107665371 > > production=# cluster co27t; > > ERROR: found multixact 105476076 from before relminmxid 107665371 > > > > But this time, regular vacuum versus full/cluster are different in > > multixact number. > > Your patch is applicable to this issue and is in 10.4 ? > > > > Best regards, > > > > Alexandre > > > > > We encountered this issue ourselves for the first time on a busy OLTP > system. It is at 9.6.8. We found that patching to 9.6.9 on a snapshot of > this system did not fix the problem, but I assume that is because the patch > in 9.6.9 only prevents the problem moving forward. Is that accurate?
Which patch in 9.6.9 are you referring to? The patch I linked to above hasn't yet been merged, much less been released.
No I was referring to this from the documentation:
This could happen if some tuples were locked (but not deleted). While queries would still function correctly, vacuum would normally ignore such pages, with the long-term effect that the tuples were never frozen. In recent releases this would eventually result in errors such as "found multixact nnnnn from before relminmxid nnnnn".
