Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts |
Дата | |
Msg-id | 20140530150006.GP28490@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
|
Список | pgsql-bugs |
On Fri, May 30, 2014 at 03:32:44PM +0200, Andres Freund wrote: > On 2014-05-30 09:29:16 -0400, Bruce Momjian wrote: > > This is a bug in 9.3 pg_upgrade as well? > > Yes. > > > Why has no one reported it before? > > My guess is that it wasn't attributed to pg_upgrade in the > past. Typically the error will only occur a fair amount of time > later. You'll just see vacuums randomly erroring out with slru.c errors > about nonexistant files :(. But how much later? pg_upgrade is pretty popular now but I am just not seeing the number of errors as I would expect: ERROR: could not access status of transaction 2072053907 DETAIL: Could not open file "pg_multixact/offsets/7B81": No such file or directory. I am not saying there is no bug, but from your analysis it would seem to be 100% of pg_upgrade'ed clusters that use multi-xacts. Is that true? If so, it seems we would need to tell everyone to remove the 0000 files if there are higher numbered ones with numbering gaps. Is this something our next minor release should fix in the multi-xacts code? Fixing pg_upgrade seems like the easy part. -- Bruce_ Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-bugs по дате отправления: