Re: Hot Standby, release candidate?

On Mon, Dec 14, 2009 at 11:07 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> * vacuum_defer_cleanup_age is very hard to tune. You'll need an estimate
>> on your transaction rate to begin with. Do we really want this setting
>> in its current form? Does it make sense as PGC_USERSET, as if one
>> backend uses a lower setting than others, that's the one that really
>> determines when transactions are killed in the standby? I think this
>> should be discussed and implemented as a separate patch.
>
> All the vacuum_*_age parameters have this characteristic, yet they
> exist.

I think it makes sense to have it be userset because someone could run
vacuum on one table with a different defer_cleanup_age for some
reason. I admit I'm having trouble coming up with a good use case.
Personally I'm fine with having parameters like this in alphas that
end up being renamed, or changed to different semantics, or even
removed by the time it's launched.

>> It doesn't seem any more wrong than using hash indexes right after
>> recovery, crash recovery or otherwise. It's certainly broken, but I
>> don't see much value in a partial fix. The bottom line is that hash
>> indexes should be WAL-logged.
>
> I know that's your thought; I'm just checking its everyone else's as
> well. We go to great lengths elsewhere in the patch to avoid queries
> returning incorrect results and there is a loss of capability as a
> result. I don't want Hash index users to view this as a feature. I don't
> feel too strongly, but it can be argued both ways, at least.

This goes back to your pluggable rmgr point. Someone could add a new
index method and get bogus results on their standby. And unlike hash
indexes where there's some hope of addressing the problem there's
nothing they can do to fix this.

It does seem like having a flag in the catalog to mark nonrecoverable
indexes and make them unavailable to query plans on the standby would
be worth its weight in code.

--
greg