Re: Beta test of Postgresql 6.5

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

BTW, I think that MVCC stuff will not be ready
for beta testing 1 Feb...

istm that the MVCC stuff could/should be the focus of this release. So
unless Vadim is already worried about this taking much longer than
through February, we should just plan around his schedule.

btw, I'd like to go through the parser at some point and (if possible)
convert the new MVCC-related parsing from (Ident strings + string tests)
to (yacc keywords). I think that can happen just before or after the
start of beta. OK?

- Tom

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, Pennsylvania 19026

On Wed, 20 Jan 1999, Thomas G. Lockhart wrote:

BTW, I think that MVCC stuff will not be ready
for beta testing 1 Feb...

istm that the MVCC stuff could/should be the focus of this release. So
unless Vadim is already worried about this taking much longer than
through February, we should just plan around his schedule.

I kinda agree here...I think that MVCC is crucial to the next release, and
if we have to hold off a little bit for that, so be it.

Let's go for our beta cycle starting the moment that Vadim states that he
is prepared, and from that day forth, *nothing*, *nadda*, gets added
unexcept to fix bugs...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On Wed, 20 Jan 1999, Thomas G. Lockhart wrote:

BTW, I think that MVCC stuff will not be ready
for beta testing 1 Feb...

istm that the MVCC stuff could/should be the focus of this release. So
unless Vadim is already worried about this taking much longer than
through February, we should just plan around his schedule.

I kinda agree here...I think that MVCC is crucial to the next release, and
if we have to hold off a little bit for that, so be it.

Let's go for our beta cycle starting the moment that Vadim states that he
is prepared, and from that day forth, *nothing*, *nadda*, gets added
unexcept to fix bugs...

Yes, but only on/after Feb 1. We have to give others warning.

-- 
  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, Pennsylvania 19026

"Thomas G. Lockhart" wrote:

BTW, I think that MVCC stuff will not be ready
for beta testing 1 Feb...

istm that the MVCC stuff could/should be the focus of this release. So
unless Vadim is already worried about this taking much longer than
through February, we should just plan around his schedule.

btw, I'd like to go through the parser at some point and (if possible)
convert the new MVCC-related parsing from (Ident strings + string tests)
to (yacc keywords). I think that can happen just before or after the
start of beta. OK?

I don't object, I just thoght that having as few keywords
as possible is good thing.

Vadim

I don't object, I just thoght that having as few keywords
as possible is good thing.

Yes, I understand the concern. But istm it's OK to do things
consistantly throughout the parser once your MVCC project has settled
down. At least as long as the "keyword explosion" stays small...

- Tom