Thanks very much!
I've decided to go straight to 8.1 though. There are just too many
performance improvements at this point that I might regret not having
and I don't want to do a dump reload again. I am about to compile it
now. If it isn't a panic grade failure in the latest 8.1 code th
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> We seem to be getting this error (in german) once in a while on a rather
> complex database:
> FEHLER: konnte auf den Status von Transaktion 0 nicht zugreifen
> DETAIL: kann Datei >>/var/databases/postgres/data/pg_subtrans/57DA<<
> nicht erstell
Rick Gigger <[EMAIL PROTECTED]> writes:
> I don't know if 2K could have passed since the last checkpoint.
> ...
> now that I think about it I was getting about 400 pages requests /
> minute and each of those would have have been doing at least 2
> transactions so yes, I guess that is very likel
On Jan 20, 2006, at 6:02 PM, Tom Lane wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
Postgres version 7.3.4
You realize of course that that's pretty old ...
That is right now. Right after it started up it went up to 0292.
So it was the latest file eh? I thought maybe you had some probl
On Fri, Jan 20, 2006 at 11:47:55PM -0500, Tom Lane wrote:
> Alfranio Correia Junior <[EMAIL PROTECTED]> writes:
> > What could cause the status ("select waiting") ?
>
> Perhaps you are using SELECT FOR UPDATE?
or SELECT func_with_side_effects() ?
-Mike
---(end of broad
On 1/21/06, Christopher Browne <[EMAIL PROTECTED]> wrote:
> > On 1/19/06, Pollard, Mike <[EMAIL PROTECTED]> wrote:
> >> Martijn van Oosterhout wrote:
> >>
> >> > Please provides natural keys for any of the following:
> >> >
> >> > - A Person
> >> > - A phone call: (from,to,date,time,duration) is no
Alfranio Correia Junior <[EMAIL PROTECTED]> writes:
> What could cause the status ("select waiting") ?
Perhaps you are using SELECT FOR UPDATE?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list arc
kevin brintnall <[EMAIL PROTECTED]> writes:
> Are you suggesting that the pair (reloid,attnum) is superior for
> identifying a pg_attribute entry?
Yes. It's just as unique, and it makes it easy to see the relationship
between the table and its columns. Moreover, it's what we're already
using in
On Fri, Jan 20, 2006 at 07:09:46PM -0500, Tom Lane wrote:
> kevin brintnall <[EMAIL PROTECTED]> writes:
> > * add OID column to pg_attribute. This permits dependencies to be
> >registered correctly in pg_shdepend.
>
> No, no ... the precedent in pg_depend is that columns are represented as
>
> On 1/19/06, Pollard, Mike <[EMAIL PROTECTED]> wrote:
>> Martijn van Oosterhout wrote:
>>
>> > Please provides natural keys for any of the following:
>> >
>> > - A Person
>> > - A phone call: (from,to,date,time,duration) is not enough
>> > - A physical address
>> > - A phone line: (phone numbers a
=Rick Gigger <[EMAIL PROTECTED]> writes:
Postgres version 7.3.4
You realize of course that that's pretty old ...
Yes. I will be upgrading immediately.
That is right now. Right after it started up it went up to 0292.
So it was the latest file eh? I thought maybe you had some problem
wi
Thanks. I'm not quite sure what version I am going to upgrade to yet.
Rick
On Jan 20, 2006, at 5:59 PM, Andrew Dunstan wrote:
Updates for FC1 are available here:
http://download.fedoralegacy.org/fedora/1/updates/i386/
they have 7.3.9 dated in March last year.
Or grab the source for 7.3.13
HI,
I am running PostgreSQL 8.0.x with a database that does not have foreign
keys. However, sometimes the following messages appear:
deadlock detected: Process 10029 waits for ShareLock on transaction
65272; blocked by process 32436.Process 32436 waits for ShareLock on
transaction 65117; blocked
Hi,
I running PostgreSQL 8.0.x with database that does not have foreign keys
and sometimes the following messages appears:
ERROR: deadlock detected
DETAIL: Process 10029 waits for ShareLock on transaction 65272; blocked
by process 32436.
Process 32436 waits for ShareLock on transaction
I wrote:
> If this theory is correct, the bug has been there since the clog code
> was first written. But the conditions for having it happen are narrow
> enough that it's not too surprising we haven't seen it before.
Actually, there seem to be a couple of unresolved bug reports that look
like th
Rick Gigger <[EMAIL PROTECTED]> writes:
> Postgres version 7.3.4
You realize of course that that's pretty old ...
> That is right now. Right after it started up it went up to 0292.
So it was the latest file eh? I thought maybe you had some problem
with a corrupted XID leading to trying to to
Updates for FC1 are available here:
http://download.fedoralegacy.org/fedora/1/updates/i386/
they have 7.3.9 dated in March last year.
Or grab the source for 7.3.13 and build it yourself.
cheers
andrew
Rick Gigger wrote:
It is the version that shipped with fedora core 1. The version
stri
It is the version that shipped with fedora core 1. The version
string from psql is (PostgreSQL) 7.3.4-RH. I assume that it must
have been the first bug since I had plenty of disk space.
On Jan 20, 2006, at 5:35 PM, Bruce Momjian wrote:
Rick Gigger wrote:
Postgres version 7.3.4
... a wh
Rick Gigger wrote:
> Postgres version 7.3.4
>
> ... a whole bunch of other files
> -rw--- 1 postgres postgres 262144 Jan 18 22:42 027D
> -rw--- 1 postgres postgres 262144 Jan 19 07:38 027E
> -rw--- 1 postgres postgres 262144 Jan 19 08:25 027F
> -rw--- 1 postgres postgres 26
Postgres version 7.3.4
... a whole bunch of other files
-rw--- 1 postgres postgres 262144 Jan 18 22:42 027D
-rw--- 1 postgres postgres 262144 Jan 19 07:38 027E
-rw--- 1 postgres postgres 262144 Jan 19 08:25 027F
-rw--- 1 postgres postgres 262144 Jan 19 09:07 0280
-rw--
kevin brintnall <[EMAIL PROTECTED]> writes:
> * add OID column to pg_attribute. This permits dependencies to be
>registered correctly in pg_shdepend.
No, no ... the precedent in pg_depend is that columns are represented as
the table's OID plus a column number. Please don't invent some rando
Fellow Hackers,
I've been working on this item for a little while, and I'm starting to see
some code come together. I wanted to solicit some feedback before I got
too far along to make sure I'm on the right track.
Here's a rough overview of what I've done so far:
---
Rick Gigger <[EMAIL PROTECTED]> writes:
> I got this message:
> 2006-01-20 11:50:51 PANIC: creation of file /var/lib/pgsql/data/
> pg_clog/0292 failed: File exists
> In 7.3. It caused the server to restart.
> Can anyone tell me what it means?
7.3.what?
What file names exist in the pg_clog di
I noticed the following code in tsearch2:
typedef uint64 TPQTGist;
static TPQTGist
makesign(QUERYTYPE * a)
{
int i;
ITEM *ptr = GETQUERY(a);
TPQTGistsign = 0;
for (i = 0; i < a->size; i++)
{
if (ptr->type == VAL)
sign |= 1 << (ptr->val %
On 1/19/06, Pollard, Mike <[EMAIL PROTECTED]> wrote:
> Martijn van Oosterhout wrote:
>
> > Please provides natural keys for any of the following:
> >
> > - A Person
> > - A phone call: (from,to,date,time,duration) is not enough
> > - A physical address
> > - A phone line: (phone numbers arn't uniqu
I got this message:
2006-01-20 11:50:51 PANIC: creation of file /var/lib/pgsql/data/
pg_clog/0292 failed: File exists
In 7.3. It caused the server to restart.
Can anyone tell me what it means?
---(end of broadcast)---
TIP 2: Don't 'kill -9' t
Simon Riggs <[EMAIL PROTECTED]> writes:
> Any holes in that thinking?
Only that it's about five times more complicated than is currently known
to be necessary ;-). How about we just implement the dynamic spill to
disk first, and not bother with the other stuff until we see problems in
the field?
On Thu, Jan 19, 2006 at 07:16:03PM -0500, Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> > I've got a fast FreeBSD/amd64 server available to run Buildfarm on.
>
> > However, I see we already have a couple of others running it.
>
> > My questions are:
> > 1) do we
On Thu, 2006-01-19 at 18:38 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > This seems to lead to a super-geometric progression in the number of
> > files required,
>
> But we double the number of batches at each step, so there are going to
> be at most 20 or so levels, and th
On Fri, Jan 20, 2006 at 01:58:16PM +, Richard Huxton wrote:
> Aside:
> Even if not using name+address as a primary key, a separate record
> should be kept of these details *at the time of the invoice* otherwise
> you'll never be able to match up a printed invoice with its digital
> source. U
Dann Corbit wrote:
When the data changes, the problems generated are not just due to
repercussions related to the child and parent tables related through the
primary key.
Someone has an invoice, and they call in with a question. A combination
of their name and address was used as a primary key.
31 matches
Mail list logo
