On 2 May 2012 13:41, Robert Haas wrote:
> So on further reflection I'm thinking it may be best just to stick
> with a hard conflict for now and see what feedback we get from beta
> testers.
Which is what I was expecting y'all to conclude once you'd looked at
the task in more detail.
And I'm hap
On Thu, Apr 26, 2012 at 8:03 PM, Robert Haas wrote:
> So, as a first step, I've committed a patch that just throws a hard
> conflict. I think we probably want to optimize this further, and I'm
> going to work investigate that next. But it seemed productive to get
> this much out of the way first
On Mon, Apr 16, 2012 at 4:13 PM, Robert Haas wrote:
> But fundamentally we all seem to be converging on some variant of the
> "soft conflict" idea.
So, as a first step, I've committed a patch that just throws a hard
conflict. I think we probably want to optimize this further, and I'm
going to wo
On Mon, Apr 16, 2012 at 1:58 PM, Simon Riggs wrote:
> If we do need to do something, then introduce concept of a visibility
> conflict.
>
> On replay:
> If feedback not set, set LSN of visibility conflict on PROCs that
> conflict, if not already set.
>
> On query:
> If feedback not set, check con
On Mon, Apr 16, 2012 at 3:02 AM, Noah Misch wrote:
> Do you refer to PD_ALL_VISIBLE as "not merely a hint" due to the requirement
> to prevent a page from simultaneously having a negative PD_ALL_VISIBLE and a
> positive visibility map bit? That is to say, PD_ALL_VISIBLE is fully a hint
> in its r
On Mon, Apr 16, 2012 at 4:26 AM, Heikki Linnakangas
wrote:
> Can we have a "soft" hot standby conflict that doesn't kill the query, but
> disables index-only-scans?
Yeah, something like that seems possible.
For example, suppose the master includes, in each
mark-heap-page-all-visible record, the
On Mon, Apr 16, 2012 at 3:19 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Can we have a "soft" hot standby conflict that doesn't kill the query,
>> but disables index-only-scans?
>
> Well, there wouldn't be any way for the planner to know whether an
> index-only scan would be safe or not.
Heikki Linnakangas writes:
> Can we have a "soft" hot standby conflict that doesn't kill the query,
> but disables index-only-scans?
Well, there wouldn't be any way for the planner to know whether an
index-only scan would be safe or not. I think this would have to look
like a run-time fallback.
On 16.04.2012 10:38, Simon Riggs wrote:
On Mon, Apr 16, 2012 at 8:02 AM, Noah Misch 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
On Mon, Apr 16, 2012 at 8:02 AM, Noah Misch 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,
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 rec
On Fri, Apr 13, 2012 at 5:33 PM, Robert Haas wrote:
> Currently, we have a problem with index-only scans in Hot Standby
> mode: the xmin horizon on the standby might lag the master, and thus
> an index-only scan might mistakenly conclude that no heap fetch is
> needed when in fact it is. I sugges
Currently, we have a problem with index-only scans in Hot Standby
mode: the xmin horizon on the standby might lag the master, and thus
an index-only scan might mistakenly conclude that no heap fetch is
needed when in fact it is. I suggested that we handle this by
suppressing generation of index-on
13 matches
Mail list logo
