Thread: Re: Beta test of Postgresql 6.5
> > 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, Pennsylvania19026
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
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, Pennsylvania19026
"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