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.
-- Simon Riggs www.2ndQuadrant.com
