On 4/18/07, Dave Dutcher <[EMAIL PROTECTED]> wrote:
I think a database with all natural keys is unrealistic. For example if you
have a table that refers to people, are you going to use their name as a
primary key? Names change all the time due to things like marriage,
divorce, or trouble with t
Thanks for your answers and feedback.
All things considered, it is easiest (and acceptable) in this case to remove
RI between the tables where the deadlocks were occurring.
We are still looking to upgrade to 8.1.latest but that is another matter...
Steve
Arnau wrote:
Hi Thor,
Thor-Michael Støre wrote:
On 2007-04-04 Arnau wrote:
Josh Berkus wrote:
Arnau,
Is there anything similar in PostgreSQL? The idea behind this
is how I can do in PostgreSQL to have tables where I can query
on them very often something like every few seconds and get
resul
On Tue, 2007-04-17 at 21:06 -0700, Craig A. James wrote:
> Merlin Moncure wrote:
> > In the context of this debate, I see this argument all the time, with
> > the implied suffix: 'If only we used integer keys we would not have
> > had this problem...'. Either the customer identifies parts with a
>
On Wed, Apr 11, 2007 at 12:50:37AM +0200, Tobias Brox wrote:
> We had problems again, caused by long running transactions. I'm
> monitoring the pg_stat_activity view, checking the query_start of all
> requests that are not idle - but this one slipped under the radar as the
> application was runnin
I think a database with all natural keys is unrealistic. For example if you
have a table that refers to people, are you going to use their name as a
primary key? Names change all the time due to things like marriage,
divorce, or trouble with the law. We have tables with 20 million rows which
ref
On Thu, Apr 05, 2007 at 03:10:43PM -0500, Erik Jones wrote:
> Nope. What we never tracked down was the factor of 10 drop in
> database transactions, not disk transactions. The write volume was
> most definitely due to the direct io setting -- writes are now being
> done in terms of the syst
"Steven Flatt" <[EMAIL PROTECTED]> writes:
> Hi, we're using Postgres 8.1.4.
> We've been seeing deadlock errors of this form, sometimes as often as
> several times per hour:
> ...
> I also see claims that this problem is fixed in 8.2, and if the fix is what
> I think it is, it's also in 8.1.6.
> C
On Fri, Mar 30, 2007 at 11:19:09AM -0500, Erik Jones wrote:
> >On Fri, Mar 30, 2007 at 04:25:16PM +0200, Dimitri wrote:
> >>The problem is while your goal is to commit as fast as possible -
> >>it's
> >>pity to vast I/O operation speed just keeping common block size...
> >>Let's say if your trans
Merlin Moncure wrote:
Since the part number is NOT the primary key, duplicate part numbers
are not a problem. If you had instead used the part number as the
primary key, you'd be dead in the water.
You are redefining the primary key to be (part_number,
obsoletion_date). Now, if you had not a
> Can someone confirm that I've identified the right fix?
I'm pretty sure that won't help you... see:
http://archives.postgresql.org/pgsql-general/2006-12/msg00029.php
The deadlock will be there if you update/insert the child table and
update/insert the parent table in the same transaction (even
Hi, we're using Postgres 8.1.4.
We've been seeing deadlock errors of this form, sometimes as often as
several times per hour:
Apr 17 13:39:50 postgres[53643]: [4-1] ERROR: deadlock detected
Apr 17 13:39:50 postgres[53643]: [4-2] DETAIL: Process 53643 waits for
ShareLock on transaction 11128328
On 4/18/07, Craig A. James <[EMAIL PROTECTED]> wrote:
Merlin Moncure wrote:
> In the context of this debate, I see this argument all the time, with
> the implied suffix: 'If only we used integer keys we would not have
> had this problem...'. Either the customer identifies parts with a
> part num
On Wed, 18 Apr 2007, Richard Huxton wrote:
And at the end of the day that's the root of the problem. It's easy to be
lulled into "well it looks like a primary key" rather than being able to
guarantee it.
In some of these cases it is guaranteed to be a primary key given all
available informat
Craig A. James wrote:
Since we're only aggregating information, we have
no control over the data that these companies provide.
And at the end of the day that's the root of the problem. It's easy to
be lulled into "well it looks like a primary key" rather than being able
to guarantee it.
--
15 matches
Mail list logo
