On 16.04.2012 10:38, Simon Riggs wrote:
> On Mon, Apr 16, 2012 at 8:02 AM, Noah Misch<noah@leadboat.com> wrote:
>> On Fri, Apr 13, 2012 at 12:33:06PM -0400, Robert Haas wrote:
>>> In the department of query cancellations, I believe Noah argued
>>> previously that this wasn't really going to cause a problem. And,
>>> indeed, if the master has a mix of inserts, updates, and deletes, then
>>> it seems likely that any recovery conflicts generated this way would
>>> be hitting about the same place in the XID space as the ones caused by
>>> pruning away dead tuples. What will be different, if we go this
>>> route, is that an insert-only master, which right now only generates
>>> conflicts at freezing time, will instead generate conflicts much
>>> sooner, as soon as the relation is vacuumed. I do not use Hot Standby
>>> enough to know whether this is a problem, and I'm not trying to block
>>> this approach, but I do want to make sure that everyone agrees that
>>> it's acceptable before we go do it, because inevitably somebody is
>>> going to get bit.
>>
>> Given sufficient doubt, we could add a GUC, say hot_standby_use_all_visible.
>> A standby with the GUC "off" would ignore all-visible indicators and also
>> decline to generate conflicts when flipping them on.
>
> I'm against adding a new GUC, especially for that fairly thin reason.
Same here.
Can we have a "soft" hot standby conflict that doesn't kill the query,
but disables index-only-scans?
In the long run, perhaps we need to store XIDs in the visibility map
instead of just a bit. If you we only stored one xid per 100 pages or
something like that, the storage overhead would not be much higher than
what we have at the moment. But that's obviously not going to happen for
9.2...
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
