On Wed, Sep 20, 2017 at 7:45 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> Right, I was thinking from the perspective of the index entry. Before
> marking index entry as dead, we do check for heaptid. So, as heaptid
> can't be reused via Page-at-a-time index vacuum, scan won't mark index
> entry as dead.
It can mark index entries dead, but if it does, they correspond to
heap TIDs that are still dead, as opposed to heap TIDs that have been
resurrected by being reused for an unrelated tuple.
In other words, the danger scenario is this:
1. A page-at-a-time scan records all the TIDs on a page.
2. VACUUM processes the page, removing some of those TIDs.
3. VACUUM finishes, changing the heap TIDs from dead to unused.
4. Somebody inserts a new tuple at one of the existing TIDs, and the
index tuple gets put on the page scanned in step 1.
5. The page-at-a-time scan resumes and kills the tuple added in step 4
by mistake, when it really only intended to kill a tuple removed in
step 2.
What prevent this is:
A. To begin scanning a bucket, VACUUM needs a cleanup lock on the
primary bucket page. Therefore, there are no scans in progress at the
time that VACUUM begins scanning the bucket.
B. If a scan begins scanning the bucket, it can't pass VACUUM, because
VACUUM doesn't release the page lock on one page before taking the one
for the next page.
C. After 0003, it becomes possible for a scan to pass VACUUM if the
table is permanent, but it won't be a problem because of the LSN
check.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers