From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Block level concurrency during recovery |
Date: | 2008-10-23 06:09:56 |
Message-ID: | 49001534.6070001@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> I'm undecided as to whether this is too much code or too little. I'm
> somewhat uncertain as to the locking requirements for the physical scan
> during a vacuum. I've worked out various options if we need to change
> this.
For the B-tree, an exclusive lock is enough to modify the contents of
the page. A cleanup lock needs to be taken on every page to ensure that
the vacuum doesn't finish and delete a heap tuple that's about to be
accessed by an index scan. That could be handled in WAL replay by
dropping the exclusive lock and re-acquiring the cleanup lock, but we
can't do that for heap vacuums.
However, we require that in b-tree vacuum, you take a cleanup lock on
*every* leaf page of the index, not only those that you modify. That's a
problem, because there's no trace of such pages in the WAL.
PS. FSM doesn't need cleanup locks.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-10-23 06:15:39 | Re: Making pg_standby compression-friendly |
Previous Message | Heikki Linnakangas | 2008-10-23 05:40:48 | Re: Deriving Recovery Snapshots |