Bruce Momjian wrote: > On Mon, Jun 8, 2015 at 11:40:43AM -0400, Tom Lane wrote: > > Robert Haas <robertmh...@gmail.com> writes: > > > So, when shall we do all of this releasing? It seems like we could do > > > stage-one of the multixact fixing this week, and then figure out how > > > to do the other stuff after PGCon. Alternatively, we can let the > > > latest round of changes that are already in the tree settle until > > > after PGCon, and plan a release for stage-one of the multixact fixing > > > then. Whichever we pick, we then need to figure out the timetable for > > > the rest of it. > > > > I think we've already basically missed the window for releases this week. > > Not that we couldn't physically do it, but that we normally give the > > packagers more than one day's notice. (There's also the fact that we've > > already asked them to do two releases in the past three weeks.) > > Yeah, I think if we needed this out in an emergency, we would do it, but > based on the volume of recent releases, it would be hard. Are we seeing > user reports of failures even on the newest released versions, or are > these preventive fixes?
* people with the wrong oldestMulti setting in pg_control (which would be due to a buggy pg_upgrade being used long ago) will be unable to start if they upgrade to 9.3.7 or 9.3.8. A solution for them would be to downgrade to 9.3.6. We had reports of this problem starting just a couple of days after we released 9.4.2, I think. * We had a customer unable to refresh their base backups once they upgraded to 9.3.7; taking a new base backup would fail with a very similar error to those above (except no buggy pg_upgrade was involved). They seem to have gotten from under that problem by removing from crontab a script that ran whole-table vacuuming more frequently than with default settings. Their data is 3 TB in size, so the basebackup takes long enough that multixact truncations occured while the base backups were running, every time, so they were unrestorable. (Actually I just checked and it seems they haven't verified that they can take a new base backup -- the new one is still running.) Anyway my point is that for some guys these bugs are pretty critical. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
