Simon Riggs wrote: > On Thu, 2010-04-22 at 11:28 +0300, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> On Thu, 2010-04-22 at 10:24 +0300, Heikki Linnakangas wrote: >>>> btree_redo: >>>>> /* >>>>> * Note that if all heap tuples were LP_DEAD then we will be >>>>> * returning InvalidTransactionId here. This seems very unlikely >>>>> * in practice. >>>>> */ >>>> 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? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
