Bruce Momjian wrote:
>
> >
> > Hi again,
> >
> > I'm trying to use your hint, but I don't find the new select sintax in the
> > docs, so excuse me for asking again.
> > If I've got it right, whe I make a SELECT ... FOR UPDATE within a connection
> > (Autocommit = off), the selected records are blocked until the connection is
> > closed, commited or rolled-back. Thus, only the same transaction can modify
> > them, and consistency is thus achieved.
> >
> > I've tried lauching two processes that make simultaneous updates on one
> > table (different rows) and simultaneous inserts on another (these processes
> > are client order imports from file). One of the processes run while the
> > other kept waiting in the first insert it atempted. Do I have to use any SQL
> > or configure something, or is this the normal behaviour?
> >
> > Thanks again for your answers.
Only syntax is implemented currently.
Please wait for 1-2 days.
> I assume you are running the snapshot, and not 6.4.*. You are actually
> using FOR UPDATE, so I think it is the snapshot.
>
> This is normal behavior, I think. I believe the issue with SELECT FOR
> UPDATE is that it has to lock the entire table. We allow non-blocking
> readers and non-blocking writers on different rows by using the
> transaction id and multi-version system. SELECT FOR UPDATE does not
> actually modify any rows, so we can't look at any transaction id.
FOR UPDATE modifies rows.
It changes t_xmax and sets HEAP_MARKED_FOR_UPDATE
flag in t_infomask.
BTW, I think that MVCC stuff will not be ready
for beta testing 1 Feb...
Vadim
