I am forwarding this to hackers to see if anyone can comment on it.
[Charset iso-8859-1 unsupported, filtering to ASCII...]
>
> -----Original Message-----
> De: Bruce Momjian <maillist@candle.pha.pa.us>
> Para: Juan Alvarez Ferrando <juan@suzuki.es>
> CC: Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>; PostgreSQL-development
> <hackers@postgreSQL.org>
> Fecha: mi_rcoles 20 de enero de 1999 12:31
> Asunto: Re: Beta test of Postgresql 6.5
>
>
> >
> >I assume you are running the snapshot, and not 6.4.*. You are actually
> >using FOR UPDATE, so I think it is the snapshot.
>
>
> Yes, I'm runnign 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.
>
> Maybe, I didn't explain my case enough. Though my question regards the
> SELECT FOR UPDATE command, I wasn't using it in the test case I explained.
>
> I have two twin processes like this:
>
> BEGIN TRANSACTION
> Read order header
> INSERT INTO GCABE VALUES (num,date,client)
> while there are order lines
> Read order line -> part_number, qty
> SELECT AVAILABLE FROM PARTS WHERE PARTNUM=part_number
> if (AVAILABLE >= qty)
> INSERT INTO ORDERLINES VALUES (part_number, qty,num)
> UPDATE PARTS SET AVAILABLE=AVAILABLE-qty WHERE PARTNUM=part_number
> endif
> endwhile
> COMMIT
>
> I run this on to different order files, from different customers and
> different part numbers (NOTE I DONT USE THE 'FOR UPDATE' SINTAX), and as I
> explained the last one to begin is blocked until the other one finishes.
>
> Best regards, and thanks again.
>
>
> Juan Alvarez Ferrando
>
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
