Re: [CORE] back-branch multixact fixes & 9.5 alpha/beta: schedule

Bruce Momjian wrote:
> On Mon, Jun  8, 2015 at 11:40:43AM -0400, Tom Lane wrote:
> > Robert Haas <robertmhaas@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