I wonder if there will be assumptions in the startup code concerning
time. What if the startup takes 18 months, would there be some sort
of problem with this approach you think?
On Aug 11, 2004, at 6:14 PM, Gaetano Mendola wrote:
Tom Lane wrote:
Somebody should hack this together and try it d
I'm working on a new machine, and i think it's got possible bad
hardware, since that seems more likely than a bug in postgresql. I'm
wondering if someone has any idea what kind of hardware failure might
cause this message:
WARNING: buffer refcount leak: [424] (freeNext=425, freePrev=423,
re
think we already fixed that in 7.4.2. We also have a few bugs still
in 7.4.2 and we need to get those fixed soon and release 7.4.3.
---
----
Brian Hirt wrote:
I'm following up on my own email and cross posting to hacker
. if it's going to stay at int, it should
probably be increased to long and the casts changed to ::int8
any suggestions on how best way to fix?
i'll supply a patch once the approach is agreed upon and the problem
has been verified.
best regards,
--brian
On May 18, 2004, at 7:37
Hello,
I've run across a pretty serious problem with pg_autovacuum.
pg_autovacuum looses track of any table that's ever been truncated
(possibly other situations too). When i truncate a table it gets a
new relfilenode in pg_class. This is a problem because pg_autovacuum
assumes pg_cla
here's a patch that joins on pg_class.oid instead of
pg_class.relfilenode, also i have renamed the table structure from
relfilenode to relid.
patch
Description: Binary data
---(end of broadcast)---
TIP 9: the planner will ignore your desire to
I recently ran across this (i think) bug relating to constraints and
functions written in plpgsql. It seems that I'm getting erroneous foreign
key violations. I've included two scripts which create the simplest test
case I can reproduce. One script has a foreign key defined and the other
one doe
I forgot to mention that this is happening on 7.0.3and 7.1.1 -- and I'm
running on a RedHat 7.0 machine.
- Original Message -
From: "Brian Hirt" <[EMAIL PROTECTED]>
To: "Postgres Hackers" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sun
Hi,
I have a question about the performance of the planner in 7.1. I've been
testing the 11/21 snapshot of the database just to get an idea of how it
will work for me when I upgrade from 7.02 I've noticed that some queries
are taking much longer and I've narrowed it down (i think) to the plan
n c_c (cost=0.00..2.02 rows=1 width=8)
Other plans not using Materialize seem to work okay.
Please contact me if I can help someone solve this problem or supply more
information. I want to help out since I rely heavily on postgres!
--Brian Hirt
--
The world's most ambitious and comprehensive PC game database project.
http://www.mobygames.com
blah.sql.gz
10 matches
Mail list logo
