On Thu, Mar 03, 2011 at 09:04:04AM -0600, Merlin Moncure wrote: > On Thu, Mar 3, 2011 at 2:16 AM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> wrote: > > 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. > > This. The mis-set flag can is likely a bug/concurrency issue etc, > but could also be a symptom of more sinister data corruption. I did > various vacuum experiments all day yesterday on my windows workstation > and was not able to produce any mis-flags. I trust iscsi more than > nfs, but maybe there is a connection here that is hardware based. hm. > do you think it would be helpful to know what is causing the > all_visible flag to get flipped? If so, the attached patch shows > which case is throwing it...
I'll apply your patch and try it. Probably can only do it for a few minutes tomorrow evening though as the output is huge and we have only limited down time availability. -dg -- David Gould da...@sonic.net 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
