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". As far as I know, one connection == 1 xaction.
Andreas Jung wrote:
Show quoted text
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?
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 x110On 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