By the way, a colleague just reproduced this problem on a 7.2.1 postgres.
-Original Message-
From: Rachit Siamwalla [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 4:27 PM
To: pgsql-hackers; Paul Menage
Subject: [HACKERS] Question whether this is a known problem in 7.1.2
This
This problem was discovered in 7.1.2. Was wondering whether this is a known problem or
not; we plan to test this on the latest postgres sometime later.
We have a large table, lets call it A, millions of rows. And in the table is a field
called time, which is TIMESTAMP type. We have an index on
i've had similar problems before. Looks like some thing is in a transaction,
blocked on something else. Then vacuum comes in, locks half the tables, and
then gets stuck on a table that the transaction has modified. Now most of
your other transactions will block forever. Then the connection limit f
I sent a message a while back on this list on why an insert onto a table A
which has a foreign key constraint to table B obtains a write (exclusive)
lock on that row on table B (basically does a select for update). The answer
was there is no SQL construct to obtain read (shared) locks on a partic
just curious, is there any reason why a plperl RPM package isn't included
with the "official" distribution (from postgres website)?
No incredible deal just to build it myself, just wondering.
-rchit
---(end of broadcast)---
TIP 5: Have you checke
Count me in for error codes. You can just see part of the code i'm using to
deal with the problem (some of the error messages changed from 7.0 to 7.1 --
i had to fix that):
def parseError(self, errval):
# first compile all the exceptions. Ideally we don't have to compile
# all
This may sound like a stupid question, and i apologize if it is, but I
couldn't find the answer in any documentation.
Every table has a implicit column oid. Does this column have an index on it?
I assume not, and I am putting an index on it anyway.
The real problem is that I have a table like t
Is there any good reason to use VARCHAR over TEXT for a string field? ie.
performance hits, etc.
Other than running into the row size limit problem, are there any large
storage / performance penalties of using TEXT for virtually all strings?
For ex. A phone number. This field probably wouldn't
Anyone know why I could possibly get this error? This doesn't happen
deterministically.
WaitOnLock: error on wakeup - Aborting this transaction
I also got this notice:
NOTICE: Deadlock detected -- See the lock(l) manual page
---
Actually, what I'm looking for in this mail is a possible way
But beforwarned that if you build the package on rpm 3.0.5, the machines
with previous versions of RPM will not be able to install that RPM. So you
will have to upgrade all of your machines (and also install a couple of
libraries, ie. popt and something else or the other). (correct me if I'm
wrong
I am having problems with transactions and foreign key constraints in
postgres 7.0-3 (RPM distribution). . The foreign key constraints were
blocking concurrent transactions. Here is an example where something blocked
but shouldn't have blocked:
create table hello10 (myid serial primary key, myval
Thanks a lot for your total and complete description of the process. (i
should have checked out the sprm first before asking). I empathize with
what you said about packaging not being a simple task, i have been through
the agony.
About putting your stuff into the postgres tree, i believe it wou
oh btw, i completely forgot to mention the minor fixes to the linux init
scripts i mentioned earlier (about 2 weeks ago) for things that perhaps
should be in the 7.1.1 release. (someone sent out a mail that they were
branching 7.1.1)
Also i never got a response on who actually packages those linu
en discussed or
explained in the past before, but i cannot find this info in a FAQ or know
what keywords to use if i want to search on the mailing list :).
-rchit
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 24, 2001 7:28 AM
To: Rachit Siamwalla
Hi,
I believe i found two minor bugs in the linux start/stop scripts for the
downloadable rpm version of postgres 7.1. I don't think these have been
reported already (i did some quik searches). Please look these over and see
if i'm just smoking something or if these bugs are valid. Also, i did a
15 matches
Mail list logo
