On Fri, May 16, 2014 at 2:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I still think this is throwing the error at the wrong place. People
> will turn on the GUC the first time it gets in their way, and then
> much later discover that the index doesn't work on a slave, and we'll
> get a bug report exactly like this one. We need a check that is tightly
> connected to actual unsafe usage, rather than basically-user-unfriendly
> complaints at a point that's not doing anything unsafe. (Well, anything
> more unsafe than it ever was.)
So there three cases where crash recovery is necessary:
1) A database crashes and does recovery when it starts up
2) A database has a hot backup taken and it's restored in a whole new place
3) A standby is replaying logs and has hot standby queries against it
or is activated and runs normally
The first two are actually safe as long as the index is quiescent.
That is, if the database crashes and there were no writes in progress
or the machine crashes and there were no writes since the last
checkpoint then the index should still be valid after a restart. A hot
backup should be fine if there were no writes to the index during the
hot backup. Obviously this is a precarious state of affairs but I
guess you're right that it's unchanged from the historical situation.
The index on the standby is a bit different. If the index has never
been touched since before the standby was created then it's ok (and
incidentally Heroku does see the occasional customer in that situation
-- they have hash indexes on archived partitions for data warehouse
queries). But if there's been a write ever since then even if it was a
long time ago the standby index is unusable. That's a lot more likely
than a backup taken while the index was being updated.
I take it you're arguing we should have an error in the standby if it
tries to use a hash index? That's seems reasonable. It might be good
to have a guc to override it (unfortunately we can't turn it into a
warning since it m
--
greg
