Re: Block level concurrency during recovery

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block level concurrency during recovery
Date: 2008-10-23 16:50:51
Message-ID: 1224780651.27145.638.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-10-23 16:54:22 Re: double-buffering page writes
Previous Message Tom Lane 2008-10-23 16:48:45 Re: Unicode escapes in literals