> 
> 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.

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.

Vadim, can you comment?

-- 
  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

Wed, 20 Jan 1999 06:09:21 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
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

Wed, 20 Jan 1999 19:50:56 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Re: Beta test of Postgresql 6.5
> 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

Wed, 20 Jan 1999 15:09:49 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: Beta test of Postgresql 6.5
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 


Wed, 20 Jan 1999 15:21:15 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: Beta test of Postgresql 6.5
> 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

Wed, 20 Jan 1999 14:49:55 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: Beta test of Postgresql 6.5
"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

Thu, 21 Jan 1999 09:10:43 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Re: Beta test of Postgresql 6.5
> 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

Thu, 21 Jan 1999 06:12:25 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: Beta test of Postgresql 6.5