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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
