From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | out of date bufmgr README |
Date: | 2003-10-31 22:15:55 |
Message-ID: | 1067638555.365.8.camel@tokyo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While reading through src/backend/storage/buffer/README, I noticed that
the following text seems to no longer be correct:
As of 7.1, the only operation that removes tuples or compacts
free space is (oldstyle) VACUUM. It does not have to implement
rule #5 directly, because it instead acquires exclusive lock at
the relation level, which ensures indirectly that no one else is
accessing pages of the relation at all.
To implement concurrent VACUUM we will need to make it obey rule
#5 fully. To do this, we'll create a new buffer manager
operation LockBufferForCleanup() that gets an exclusive lock and
then checks to see if the shared pin count is currently 1. If
not, it releases the exclusive lock (but not the caller's pin)
and waits until signaled by another backend, whereupon it tries
again. The signal will occur when UnpinBuffer decrements the
shared pin count to 1. As indicated above, this operation might
have to wait a good while before it acquires lock, but that
shouldn't matter much for concurrent VACUUM. The current
implementation only supports a single waiter for pin-count-1 on
any particular shared buffer. This is enough for VACUUM's use,
since we don't allow multiple VACUUMs concurrently on a single
relation anyway.
Could someone who's aware of the bufmgr changes made for 7.2's lazy
VACUUM comment on how this should be updated?
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2003-10-31 22:19:51 | Re: Experimental patch for inter-page delay in VACUUM |
Previous Message | Joe Conway | 2003-10-31 22:10:26 | Re: Annotated release notes |