Re: About that re-release ...
От | Robert Haas |
---|---|
Тема | Re: About that re-release ... |
Дата | |
Msg-id | CA+TgmoYj_cZ-KpTH3QvuW0mTA-PoZz=y8qUinai8H5FZ-ZcvvA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: About that re-release ... (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, May 27, 2015 at 11:08 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> What about http://www.postgresql.org/message-id/20150527222142.GE5885@postgresql.org >>> ? >> >>> I believe that is also a 9.4.2 regression, and a serious one. >> >> Oh? There was nothing in the thread that suggested to me that it was >> a new-in-9.4.2 bug. > > I think it is. The executive summary here is that 9.4.2 and 9.3.7 fail to start if pg_control's oldestMultiXid points to a pg_multixact/offsets file that does not exist. Earlier versions tolerated that, but the new versions don't. So people who have this situation will be unable to start the database after upgrading. That's quite bad. However, the new set of releases is not entirely responsible for the problem, because the situation that causes 9.4.2 and 9.3.7 to fail to start isn't supposed to occur. The database really SHOULD NOT remove an offsets file that does not precede oldestMultiXid, and if it does, then either oldestMultiXid is set wrong (which would be a bug), or the database removed an offsets file to which references may still exist (which would be a data loss issue). Thomas Munro, Alvaro, and I have been discussing this on Skype, but have so far been unable to construct a series of events which would lead to an occurrence of this kind. We speculate that pg_upgrade may play a role, but there's no proof of that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: