Update comment in heapgetpage() regarding PD_ALL_VISIBLE vs. Hot Standby.
authorRobert Haas <rhaas@postgresql.org>
Fri, 14 Dec 2012 20:44:38 +0000 (15:44 -0500)
committerRobert Haas <rhaas@postgresql.org>
Fri, 14 Dec 2012 20:44:38 +0000 (15:44 -0500)
Pavan Deolasee, slightly modified by me

src/backend/access/heap/heapam.c

index e114d3dc45b1c111b9982443bec94115df69446e..186fb8711b5b786f9bd7ea1956097ab85139610f 100644 (file)
@@ -260,10 +260,23 @@ heapgetpage(HeapScanDesc scan, BlockNumber page)
 
    /*
     * If the all-visible flag indicates that all tuples on the page are
-    * visible to everyone, we can skip the per-tuple visibility tests. But
-    * not in hot standby mode. A tuple that's already visible to all
+    * visible to everyone, we can skip the per-tuple visibility tests.
+    *
+    * Note: In hot standby, a tuple that's already visible to all
     * transactions in the master might still be invisible to a read-only
-    * transaction in the standby.
+    * transaction in the standby. We partly handle this problem by tracking
+    * the minimum xmin of visible tuples as the cut-off XID while marking a
+    * page all-visible on master and WAL log that along with the visibility
+    * map SET operation. In hot standby, we wait for (or abort) all
+    * transactions that can potentially may not see one or more tuples on the
+    * page. That's how index-only scans work fine in hot standby. A crucial
+    * difference between index-only scans and heap scans is that the
+    * index-only scan completely relies on the visibility map where as heap
+    * scan looks at the page-level PD_ALL_VISIBLE flag. We are not sure if the
+    * page-level flag can be trusted in the same way, because it might get
+    * propagated somehow without being explicitly WAL-logged, e.g. via a full
+    * page write. Until we can prove that beyond doubt, let's check each
+    * tuple for visibility the hard way.
     */
    all_visible = PageIsAllVisible(dp) && !snapshot->takenDuringRecovery;