otiation_limit to 0 in your postgresql.conf and
restart postgreSQL.
regards,
--
Rafael Martinez Guerrero
Center for Information Technology
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/rafael/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
On Mon, 2007-02-12 at 08:17 +0100, dfx wrote:
> Dear Sirs,
>
> I am workink on Windows 2000 with PgAdmin III v. 1.6.2
>
> If I open an sql file created with UTF8 encoding the characters with accent
> are not reproduced correctly.
> If I open the same file with MS Word or JEdit or also PgAdmin III
Hello
We had a strange problem yesterday in one of our servers using PITR
(postgresql 8.1.4).
The script used by archive_command is designed to refuse to overwrite
any pre-existing archive file. Yesterday this situation happened and it
refused to overwrite a file, filling the log file with this
On Mon, 2006-05-22 at 11:00, Peter Eisentraut wrote:
> Am Montag, 22. Mai 2006 09:17 schrieb Rafael Martinez, Guerrero:
> > To have a database on a NFS filesystem is a disaster waiting to happen,
> > specially if the NFS server is running on Linux. Not to talk on the
> > p
On Mon, 2006-05-22 at 10:25, Greg Stark wrote:
> Using TCP with NFS is only really helpful when you have a high latency high
> bandwidth link which isn't going to be a terribly positive environment for
> postgres.
>
Well, having a protocol that by definition says that datagrams may
arrive out of
On Mon, 2006-05-22 at 06:15, SODA Noriyuki wrote:
Hei
> We've encountered failures of "make check", when we put PostgreSQL
> data directory on a NFS filesystem or a tmpfs filesystem.
> It doesn't always fail, but fails occasionally.
>
To have a database on a NFS filesystem is a disaster waiting
Hello
Today, one user complained that one of the tickets in our system had
disappeared some places but could be accessed other places. I thought
this was weird and startet debugging.
I have found out the sql statement with 'problems'. Can anybody explain
me why A) returns 12 rows and B) returns 1
On Fri, 2005-12-09 at 08:45, gabor wrote:
[...]
>
> are there any cases, where a normal vacuum is unable to reclaim some
> space
Hello
We have det same problem in some databases running 7.4.8. Having
max_fsm_pages and max_fsm_relations properly configurated does not help.
It looks like
On Fri, 2005-03-18 at 15:58, Tom Lane wrote:
> Rafael Martinez <[EMAIL PROTECTED]> writes:
> > On Thu, 2005-03-17 at 10:17 -0500, Tom Lane wrote:
> >> Is that a plain text, tar, or custom dump (-Ft or -Fc)? Is the behavior
> >> different if you just write to stdout instead of using --file?
>
> >
On Thu, 2005-03-17 at 15:09, Lonni J Friedman wrote:
> On Thu, 17 Mar 2005 14:05:35 +0100, Rafael Martinez Guerrero
> <[EMAIL PROTECTED]> wrote:
> > Hello
> >
> > We are having problems with pg_dump.
> >
> > We are trying to dump a 30GB+ database using
On Thu, 2005-03-17 at 15:05, Michael Kleiser wrote:
> I found on http://www.madeasy.de/7/ext2.htm (in german)
> ext2 can't have bigger files than 16GB if blocksize is 1k.
> Ext3 is ext2 with journaling.
>
[]
We use 4k. And as I said, we can generate files bigger than 16GB with
other
Hello
We are having problems with pg_dump.
We are trying to dump a 30GB+ database using pg_dump with the --file
option. In the beginning everything works fine, pg_dump runs and we get
a dumpfile. But when this file becomes 16GB it disappears from the
filesystem, pg_dump continues working without
Hello
I am trying to find out when 'Point-in-time data recovery' functionality
will be available with postgreSQL but I can not find concrete info about
this.
References in mailinglists talk about version 7.4 and in the TODO list
is under the section 'urgent'.
Anybody knows when this functionalit
13 matches
Mail list logo
