Re: Race conditions, race conditions!

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Race conditions, race conditions!
Date: 2005-08-12 22:42:46
Message-ID: 2226.1123886566@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Patch applied. Thanks.
> * block is not currently in memory.
> */
> bufHdr = BufferAlloc(reln, blockNum, &found);
> + /* we are guaranted that nobody else has touched this will-be-new block */
> + Assert(!(found && isExtend));
> if (found)
> BufferHitCount++;
> }

This patch is utterly wrong. Please revert it.

The case it is Asserting can't happen is explained in the comment a
couple dozen lines further down:

* try to extend a relation
* read smgrnblocks to find the current relation length
* allocate an empty buffer for the N+1'st page of the rel
* call smgrextend
* smgrextend fails for some reason (eg, no space left on disk)
* buffer remains present, but is not BM_VALID
* awhile later, try to extend relation again
* read smgrnblocks to find the current relation length
* allocate a buffer for the N+1'st page of the rel

This is entirely likely to find the same non-BM_VALID buffer that was
assigned in the first iteration.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2005-08-12 22:43:59 Re: PATCH to allow concurrent VACUUMs to not lock each
Previous Message Alvaro Herrera 2005-08-12 22:42:09 Re: [HACKERS] Autovacuum loose ends