On Fri, Jan 6, 2012 at 12:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I started to wonder how likely it would be that some other process would > sit on a buffer pin for so long as to allow 134217727 iterations of > ReadBufferExtended, even given the slowdowns associated with > CLOBBER_CACHE_ALWAYS. This led to some fruitless searching for possible > deadlock conditions, but eventually I realized that there's a much > simpler explanation: if PrivateRefCount > 1 then > ConditionalLockBufferForCleanup always fails. This means that once > ConditionalLockBufferForCleanup has failed once, the currently committed > code in lazy_vacuum_heap is guaranteed to loop until it gets a failure > in enlarging the ResourceOwner buffer-reference array. Which in turn > means that neither of you ever actually exercised the skip case, or > you'd have noticed the problem. Nor are the current regression tests > well designed to exercise the case. (There might well be failures of > this type happening from time to time in autovacuum, but we'd not see > any reported failure in the buildfarm, unless we went trawling in > postmaster logs.) > > So at this point I've got serious doubts as to the quality of testing of > that whole patch, not just this part.
I tested the case where we skip a block during the first pass, but I admit that I punted on testing the case where we skip a block during the second pass, because I couldn't think of a good way to exercise it. Any suggestions? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
