We have just finished upgrading Postgres from 7.2 to 8, and I must live
right or something because there was only one glitch. When the dump
from 7.2 was restored into 8, some foreign key references which should
have been initially deferred had become non-deferrable. I had to
re-define those r
Hi,
I'm currently testing online backups, and I'm facing the problem of a missing
WAL when I do the backup : the current WAL isn't archived when I save the
archives, and is required to recover...
I've read in the mailing list archives that it can be solved by copying the
current WAL from pg_xlo
On Fri, Apr 15, 2005 at 12:31:28AM -0700, Bob Smith wrote:
> We have just finished upgrading Postgres from 7.2 to 8, and I must live
> right or something because there was only one glitch. When the dump
> from 7.2 was restored into 8, some foreign key references which should
> have been initial
Hello...
Postgres 8.0.1 is running on Debian with 2.6.10 kernel with 12GB of RAM,
where 2GB is for shared memory:
echo 2147483648 > /proc/sys/kernel/shmall
echo 2147483648 > /proc/sys/kernel/shmmax
Also overcommit_memory is changed to not "overcommit":
pgsql1:/mnt/var# cat /proc/sys/vm/overcommit
Bob Smith <[EMAIL PROTECTED]> writes:
> We have just finished upgrading Postgres from 7.2 to 8, and I must live
> right or something because there was only one glitch. When the dump
> from 7.2 was restored into 8, some foreign key references which should
> have been initially deferred had becom
Marcin Giedz <[EMAIL PROTECTED]> writes:
> Why I still have "out of memory" despite of changing not
> overcommit_memory?
Because the 2.6.10 kernel is buggy :-( See this thread:
http://archives.postgresql.org/pgsql-general/2005-04/msg00342.php
regards, tom lane
--
Ruud,
thanx for your reply.
I am narrowing down on the problem...found that Suse 9.2 has a lot of
memory related problems.
reverted back to 9.1 and rebuilding the app..will post an update.
you suggestion will not work for me though...i need to check existing
records and create new records..which
Hi folks,
we've got an quite large table with 17 columns and now >15k rows.
The table works also as an journal will continously grow day by day.
Man of the columns (mostly text) aren't needed anymore if the tuple
has reached a certain age.
So I thought about clearing the unnecessary fields of
If you setup rules on the view and just have the application select,
insert, update, and delete from the view instead of the raw tables you
won't need to change your application at all. Though you do need to be
aware that you can't easily enforce uniqueness across multiple tables.
As for clearing
For several weeks now we have been experiencing fairly
severe database corruption upon clean reboot. It is very
repeatable, and the corruption is of the following forms:
ERROR: could not access status of transaction foo
DETAIL: could not open file "bar": No such file or directory
ERROR: inval
unsubscribe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Tom Lane wrote:
"Chris Hoover" <[EMAIL PROTECTED]> writes:
... However, I am having some difficulty installing the
postgresql.org RH 3.0 rpms for Postgresql 8.0.2.
Up until really recently (read: not yet shipped for Red Hat, and I'm
not sure about the PGDG RPMs), the 8.0 RPMs had the wrong
Hi Ian;
I think it is important to figure out why this is happening. I would
not want to run any production databases on systems that were failing
like this.
I am trying to figure out what are the likely causes of the errors...
1) Any other computers suffer random application crashes, power do
Hi Chris,
> I think it is important to figure out why this is happening. I would
> not want to run any production databases on systems that were failing
> like this.
You and me both :) (in our application though, it is not a total
disaster to lose the last 5 minutes of transactions, it is a
>Ben Kim <[EMAIL PROTECTED]> writes:
>> Is there a way to associate them so I know which statement came from which
>> connection?
> Log the PID originating each message.
> regards, tom lane
This is a follow up in addition to the log pid. It's a vanilla solution,
but we trie
Użytkownik Tom Lane napisał:
Marcin Giedz <[EMAIL PROTECTED]> writes:
Why I still have "out of memory" despite of changing not
overcommit_memory?
Because the 2.6.10 kernel is buggy :-( See this thread:
http://archives.postgresql.org/pgsql-general/2005-04/msg00342.php
OK Thankx
But w
16 matches
Mail list logo
