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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers