On Thu, 2008-10-23 at 19:21 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > It would also be possible to introduce a special tweak there which is > > that if the block is not in cache, don't read it in at all. If its not > > in cache we know that nobody has a pin on it, so don't need to read it > > in just to say "got the lock". That icing for later. > > Heh, that's clever :-). We could actually use a method like that to > solve the whole problem. After the (replay of the) b-tree vacuum is > finished, scan through all shared buffers, and get a vacuum lock on > every page of that index that's in cache. Groveling through all shared > buffers would be slower for small indexes, though.
Well, re-examining all of the assumptions in the code seems to have been worthwhile so far. I think that makes 4 significant tweaks that have come out of the Search For Hot Standby. > I believe the "vacuum lock every leaf page" behavior is only needed for > system catalogs. So we will still need it then. Which is good 'cos I just wrote it. > You have other issues with those still, namely that > table locks are not yet taken appropriately, so I'm not sure if this is > worth worrying about until that's done. Please explain. If you know of a correctness issue, please say. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers