Обсуждение: Re: [GENERAL] concurrent writes
On 29 Jul 2003 at 12:48, Andreas Jung wrote: > On Tue, 2003-07-29 at 12:42, Shridhar Daithankar wrote: > > On 29 Jul 2003 at 12:33, Andreas Jung wrote: > > > we are running Postgres 7.3.3 successfully on our portal sites > > > under Solaris. For a new project we have the requirement that > > > N processes need to write update/insert within the same time and within > > > the same transaction data in one table. > > > > What does it mean by same transaction data? > > should read "update/insert within the same time and within the same > transaction in one table" So you want to update same table more than once in a single transaction? That should work.. > > >More detailed: every process > > > opens its own connection, starts a transaction, updates *different* rows > > > and then commits. According to our postgres adminstrator, Postgres seems > > > to behave differently on Linux and Solaris. Any ideas on that? > > > > How it is different? It should be same, right? > > Our experience was that the complete table has been locked (Solaris) > but row-level locking was working with Linux. Whoa!! That's something. How did you conclude it is locked. If you can produce some reproducible test case, this would be a big showstopper bug.. Bye Shridhar -- flannister, n.: The plastic yoke that holds a six-pack of beer together. -- "Sniglets", Rich Hall & Friends
On 29 Jul 2003 at 13:07, Andreas Jung wrote: > On Tue, 2003-07-29 at 13:02, Shridhar Daithankar wrote: > > On 29 Jul 2003 at 12:48, Andreas Jung wrote: > > > Our experience was that the complete table has been locked (Solaris) > > > but row-level locking was working with Linux. > > > > Whoa!! That's something. How did you conclude it is locked. If you can produce > > some reproducible test case, this would be a big showstopper bug.. > > > > This problem appeard in 7.3.2 but it seems to have been fixed in 7.3.3. > Our administrator complained that there has not been a notice in the > CHANGELOG...so I am hestitating about choosing Postgres vs. Oracle :-) Even with 7.3.2, do you have a independently reproducible test case? It should help hackers to look into it. Bye Shridhar -- Matz's Law: A conclusion is the place where you got tired of thinking.
Andreas Jung <andreas.jung@haufe.de> writes: > On Tue, 2003-07-29 at 13:02, Shridhar Daithankar wrote: >>> Our experience was that the complete table has been locked (Solaris) >>> but row-level locking was working with Linux. >> >> Whoa!! That's something. How did you conclude it is locked. If you can produce >> some reproducible test case, this would be a big showstopper bug.. > This problem appeard in 7.3.2 but it seems to have been fixed in 7.3.3. > Our administrator complained that there has not been a notice in the > CHANGELOG. That's because there was no such fix. I'd be interested to see your test case. regards, tom lane
On Tue, Jul 29, 2003 at 01:07:57PM +0200, Andreas Jung wrote: > > This problem appeard in 7.3.2 but it seems to have been fixed in 7.3.3. > Our administrator complained that there has not been a notice in the > CHANGELOG...so I am hestitating about choosing Postgres vs. Oracle :-) I think your administrator is talking out of his hat. We switch back and forth between Linux and Solaris all the time here, and PostgreSQL works the same all the time. A -- ---- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M2P 2A8 +1 416 646 3304 x110
On Tue, 2003-07-29 at 13:02, Shridhar Daithankar wrote: > On 29 Jul 2003 at 12:48, Andreas Jung wrote: > > > On Tue, 2003-07-29 at 12:42, Shridhar Daithankar wrote: > > > On 29 Jul 2003 at 12:33, Andreas Jung wrote: > > > > we are running Postgres 7.3.3 successfully on our portal sites > > > > under Solaris. For a new project we have the requirement that > > > > N processes need to write update/insert within the same time and within > > > > the same transaction data in one table. > > > > > > What does it mean by same transaction data? > > > > should read "update/insert within the same time and within the same > > transaction in one table" > > So you want to update same table more than once in a single transaction? That > should work.. > > > > >More detailed: every process > > > > opens its own connection, starts a transaction, updates *different* rows > > > > and then commits. According to our postgres adminstrator, Postgres seems > > > > to behave differently on Linux and Solaris. Any ideas on that? > > > > > > How it is different? It should be same, right? > > > > Our experience was that the complete table has been locked (Solaris) > > but row-level locking was working with Linux. > > Whoa!! That's something. How did you conclude it is locked. If you can produce > some reproducible test case, this would be a big showstopper bug.. > This problem appeard in 7.3.2 but it seems to have been fixed in 7.3.3. Our administrator complained that there has not been a notice in the CHANGELOG...so I am hestitating about choosing Postgres vs. Oracle :-) -aj
On Tue, 2003-07-29 at 13:16, Shridhar Daithankar wrote: > On 29 Jul 2003 at 13:07, Andreas Jung wrote: > > > On Tue, 2003-07-29 at 13:02, Shridhar Daithankar wrote: > > > On 29 Jul 2003 at 12:48, Andreas Jung wrote: > > > > Our experience was that the complete table has been locked (Solaris) > > > > but row-level locking was working with Linux. > > > > > > Whoa!! That's something. How did you conclude it is locked. If you can produce > > > some reproducible test case, this would be a big showstopper bug.. > > > > > > > This problem appeard in 7.3.2 but it seems to have been fixed in 7.3.3. > > Our administrator complained that there has not been a notice in the > > CHANGELOG...so I am hestitating about choosing Postgres vs. Oracle :-) > > Even with 7.3.2, do you have a independently reproducible test case? It should > help hackers to look into it. > I need to ask our postgres god and let you know. Andreas