Re: Re: Buffer access rules, and a probable bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Vadim Mikheev <vmikheev(at)sectorbase(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Buffer access rules, and a probable bug
Date: 2001-07-03 17:06:25
Message-ID: 24933.994179985@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> Tom Lane wrote:
>> I believe that nbtree.c's btbuild() code is currently in violation of
>> these rules, because it calls HeapTupleSatisfiesNow() while holding a
>> pin but no lock on the containing buffer.

> OK, we had better avoid using heapam routines in btbuild() ?

On further thought, btbuild is not that badly broken at the moment,
because CREATE INDEX acquires ShareLock on the relation, so there can be
no concurrent writers at the page level. Still, it seems like it'd be a
good idea to do "LockBuffer(buffer, BUFFER_LOCK_SHARE)" here, and
probably also to invoke HeapTupleSatisfiesNow() via the
HeapTupleSatisfies() macro so that infomask update is checked for.
Vadim, what do you think?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-07-03 17:34:08 Re: selecting from cursor
Previous Message Bruce Momjian 2001-07-03 16:41:01 Re: JDBC Support - prepared Statements?