Thread: concurrent writes
hi, 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. 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? Thanks, Andreas
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? >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? Bye Shridhar -- QOTD: "I may not be able to walk, but I drive from the sitting posistion."
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" > > > >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. -aj
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 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 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.
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
On Tue, 2003-07-29 at 05: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" How can N number of transactions write into the database, all within the *same* transaction? -- +-----------------------------------------------------------------+ | Ron Johnson, Jr. Home: ron.l.johnson@cox.net | | Jefferson, LA USA | | | | "I'm not a vegetarian because I love animals, I'm a vegetarian | | because I hate vegetables!" | | unknown | +-----------------------------------------------------------------+
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
If I understand your idea, and Postgres, this is like saying you want multiple backend processes, and definite, "NO". Asfar as I know, one connection == 1 xaction. Andreas Jung wrote: > hi, > > 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. 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? > > Thanks, > Andreas > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html >
On Tue, Jul 29, 2003 at 12:33:06PM +0200, Andreas Jung wrote:
> hi,
>
> we are running Postgres 7.3.3 successfully on our portal sites
There's a nasty bug in 7.3.3 which is fixed in 7.3.4.
> N processes need to write update/insert within the same time and within
> the same transaction data in one table. More detailed: every process
> opens its own connection, starts a transaction, updates *different* rows
> and then commits.
These two descriptions are not of the same thing. Different
processes cannot share the same transaction, unless they're using the
same connection.
> According to our postgres adminstrator, Postgres seems
> to behave differently on Linux and Solaris. Any ideas on that?
Differently how? Start up time for a connection is sure worse:
fork() on Solaris is slow as my dog with his foot in a bandage.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
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