Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group