On 03.03.2011 09:12, daveg wrote:
Question: what would be the consequence of simply patching out the setting
of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
problem (big assumption perhaps) then simply never setting it would at least
avoid the possibility of returning wrong answers, presumably at some
performance cost. We possibly could live with that until we get a handle
on the real cause and fix.
Yes. With that assumption.
If you really want to do that, I would suggest the attached patch
instead. This just disables the optimization in seqscans to trust it, so
an incorrectly set flag won't affect correctness of query results, but
the flag is still set as usual and you still get the warnings so that we
can continue to debug the issue.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 7dcc601..d53aede 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -255,6 +255,11 @@ heapgetpage(HeapScanDesc scan, BlockNumber page)
* transaction in the standby.
*/
all_visible = PageIsAllVisible(dp) && !snapshot->takenDuringRecovery;
+ /*
+ * XXX: there seems to be something wrong with the way the flag is set,
+ * so don't trust it. Remove this when the cause is found.
+ */
+ all_visible = false;
for (lineoff = FirstOffsetNumber, lpp = PageGetItemId(dp, lineoff);
lineoff <= lines;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
