On 8/21/07, Ed L. <pgsql@bluepolka.net> wrote:
> On Tuesday 21 August 2007 1:45 pm, Scott Marlowe wrote:
> > If you have a large db in 7.4.6, you should do two things.
> >
> > 1: Update to 7.4.19 or whatever the latest flavor of 7.4 is,
> > right now. There are a few known data eating bugs in 7.4.6.
>
> Sounds like good advice from a strictly technical viewpoint.
> Unfortunately, in our particular real world, there are also
> political, financial, and resource constraints and impacts from
> downtime that at times outweigh the technical merits of
> upgrading 'right now'.
Well, given the very real possibility of the entire database being
lost due to the bugs present in 7.4.6, and the fact that an upgrade
consists of pg_ctl stop;rpm -Uvh postgresql-7.4.xx;pg_ctl start I
can't really accept that as a reasonable argument.
I too work in the socalled "real world" and it took me almost a month
to get an update scheduled from 7.4.7 to 7.4.13 or so when some
serious bug fixes came out. I can't remember the exact version after
7.4.7 that had the bug fixes I considered necessary off the top of my
head back then.
When is your next scheduled maintenance window? I would definitely
schedule the update then. 5 minutes downtime versus hours or days if
the db gets corrupted seems a reasonable trade-off. Plus that 5
minutes of downtime can be scheduled. Murphy dictates that if your
data gets corrupted it will not happen at 2am when you're doing
maintenance. It will happen wednesday at 12:30pm while you're at
lunch with your boss discussing your compensation. :)
> > > update pg_index
> > > set indisprimary = 't'
> > > where indexrelid = <my non-null unique index oid>
> >
> > I wouldn't bet on that working right. Others know the
> > internals of the db better than me, but that looks like a foot
> > gun.
>
> I'd still love to hear from any who know the internals well
> enough to say if this should work or if it's a bad idea. It
> appears to work in some cursory testing.
Is this a unique index? If it is, and you set the field(s) to not
null i would think that setting indisprimary might work. But I'd test
it on a test database to be sure.
