Excerpts from Heikki Linnakangas's message of mié jun 08 05:45:35 -0400 2011: > On 08.06.2011 12:36, Dan Ports wrote:
> > 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 think that is only relevant for queries like "SELECT * FROM table > WHERE ctid = '(12,34)'. You might expect that we take a lock on that > physical part of the heap, so that an INSERT that falls on that slot > would conflict, but one that falls elsewhere does not. At the moment, a > TidScan only takes a predicate lock tuples that exist, it doesn't try to > lock the range like an IndexScan would. > > The physical layout of the table is an implementation detail that the > application shouldn't care about, so I don't feel sorry for anyone doing > that. Maybe it's worth mentioning somewhere in the docs, though. What about UPDATE WHERE CURRENT OF? Also, people sometimes use CTID to eliminate duplicate rows. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
