On Fri, Jun 1, 2012 at 10:54 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Lonni J Friedman <netllama@xxxxxxxxx> writes: >> On Fri, Jun 1, 2012 at 10:34 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >>> This seems to have been noticed and fixed in HEAD: >>> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=b4e0741727685443657b55932da0c06f028fbc00 >>> I wonder whether that should've been back-patched. > >> Thanks for your reply. I won't even pretend to understand what that >> fix does. Is this behavior something that is blatantly broken, or >> harmless, or somewhere in between? Should I expect autovacuum to >> eventually complete succesfully when it stumbles into this scenario? > > Well, the problem with the original code was that it would recheck the > visibility map's file size anytime somebody tried to check a bit beyond > the end of the map. If the map isn't there (which is not an error case) > this would result in a useless open() attempt for each table page > scanned by vacuum. So ordinarily I would say that yes you could expect > autovac to complete eventually. However ... > >> Before dropping & recreating the table, yes it had millions of rows, >> and millions of updates. But since then, all I did was insert a >> single row, and watched autovacuum wedge itself in that seemingly >> infinite loop. I ended up doing a 'kill -2' on the autovacuum PID >> that was misbehaving, disabled autovacuuming the table, and went about >> what I needed to get done as an interim solution. > > ... if you really did drop and recreate the table, then at this point > it should only have a single page, I would think. It might be worth > checking the actual file size. pg_relation_size('tablename') is > probably the quickest way. Unfortunately, I've since inserted several million rows into this table, so I'm guessing its too late now to check the size? -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
