On Wed, Jun 8, 2011 at 5:36 AM, Dan Ports <d...@csail.mit.edu> wrote: > On Wed, Jun 08, 2011 at 11:23:48AM +0300, Heikki Linnakangas wrote: >> AFAICS, the check for page lock is actually unnecessary. A page-level >> lock on a heap only occurs when tuple-level locks are promoted. It is >> just a coarser-grain representation of holding locks on all tuples on >> the page, *that exist already*. It is not a "gap" lock like the index >> locks are, it doesn't need to conflict with inserting new tuples on the >> page. In fact, if heap_insert chose to insert the tuple on some other >> heap page, there would have been no conflict. > > Yes, it's certainly unnecessary now, given that we never explicitly > take heap page locks, just tuple- or relation-level. > > The only thing I'd be worried about is that at some future point we > might add heap page locks -- say, for sequential scans that don't read > the entire relation -- and expect inserts to be tested against them. > I'm not sure whether we'd actually do this, but we wanted to keep the > option open during development.
I don't think this is the right time to be rejiggering this stuff anyway. Our bug count is -- at least to outward appearances -- remarkably low at the moment, considering how much stuff we jammed into this release. Let's not hastily change things we might later regret having changed. -- 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
