On Thu, 2010-04-22 at 12:18 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2010-04-22 at 11:56 +0300, Heikki Linnakangas wrote:
> >
> >>>>>> If none of the removed heap tuples were present anymore, we currently
> >>>>>> return InvalidTransactionId, which kills/waits out all read-only
> >>>>>> queries. But if none of the tuples were present anymore, the read-only
> >>>>>> queries wouldn't have seen them anyway, so ISTM that we should treat
> >>>>>> InvalidTransactionId return value as "we don't need to kill anyone".
> >>>>> That's not the point. The tuples were not themselves the sole focus,
> >>>> Yes, they were. We're replaying a b-tree deletion record, which removes
> >>>> pointers to some heap tuples, making them unreachable to any read-only
> >>>> queries. If any of them still need to be visible to read-only queries,
> >>>> we have a conflict. But if all of the heap tuples are gone already,
> >>>> removing the index pointers to them can'ẗ change the situation for any
> >>>> query. If any of them should've been visible to a query, the damage was
> >>>> done already by whoever pruned the heap tuples leaving just the
> >>>> tombstone LP_DEAD item pointers (in the heap) behind.
> >>> You're missing my point. Those tuples are indicators of what may lie
> >>> elsewhere in the database, completely unreferenced by this WAL record.
> >>> Just because these referenced tuples are gone doesn't imply that all
> >>> tuple versions written by the as yet-unknown-xids are also gone. We
> >>> can't infer anything about the whole database just from one small group
> >>> of records.
> >> Have you got an example of that?
> >
> > I don't need one, I have suggested the safe route. In order to infer
> > anything, and thereby further optimise things, we would need proof that
> > no cases can exist, which I don't have. Perhaps we can add "yet", not
> > sure about that either.
>
> It's good to be safe rather than sorry, but I'd still like to know
> because I'm quite surprised by that, and got me worried that I don't
> understand how hot standby works as well as I thought I did. I thought
> the point of stopping replay/killing queries at a b-tree deletion record
> is precisely that it makes some heap tuples invisible to running
> read-only queries. If it doesn't make any tuples invisible, why do any
> queries need to be killed? And why was it OK for them to be running just
> before replaying the b-tree deletion record?
I'm sorry but I'm too busy to talk further on this today. Since we are
discussing a further optimisation rather than a bug, I hope it is OK to
come back to this again later.
-- Simon Riggs www.2ndQuadrant.com
