Le 29/03/2010 04:04, Nilesh Govindarajan a écrit :
> Hi, it seems to be working now. Can somebody explain to me how ? See
> this pg_hba.conf -
>
> # "local" is for Unix domain socket connections only
> local all root trust
> local all all md5
> # IPv4 local connections:
> #host all root 127.0.0.1/
On 03/29/2010 12:50 PM, Guillaume Lelarge wrote:
Le 29/03/2010 04:04, Nilesh Govindarajan a écrit :
Hi, it seems to be working now. Can somebody explain to me how ? See
this pg_hba.conf -
# "local" is for Unix domain socket connections only
local all root trust
local all all md5
# IPv4 local co
Hi,
is it safe to move the PGDATA directory from one system to another when
migrating from one operating system to another?
For example: migrating from Debian to RHEL, or from RHEL4 to RHEL5?
The database is of course shutdown properly, and the PG major versions match.
Or is a dump/restore neces
Le 29/03/2010 11:31, "Martin Münstermann" a écrit :
> [...]
> is it safe to move the PGDATA directory from one system to another when
> migrating from one operating system to another?
> For example: migrating from Debian to RHEL, or from RHEL4 to RHEL5?
> The database is of course shutdown properl
Hi,
> is it safe to move the PGDATA directory from one system to another when
> migrating from one operating system to another?
> For example: migrating from Debian to RHEL, or from RHEL4 to RHEL5?
> The database is of course shutdown properly, and the PG major versions match.
> Or is a dump/rest
Hi,
> > is it safe to move the PGDATA directory from one system to another when
> migrating from one operating system to another?
> > For example: migrating from Debian to RHEL, or from RHEL4 to RHEL5?
> > The database is of course shutdown properly, and the PG major versions
> match.
> > Or is a
Only out of curiosity, is your current server 32 bit or 64?
Are you migrating 32 to 32 or 64 to 64?
Thank you
Renato
Renato Oliveira
Systems Administrator
e-mail: renato.olive...@grant.co.uk
Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/
Grant Instruments (Cambridge)
Hi,
> > is it safe to move the PGDATA directory from one system to another when
> migrating from one operating system to another?
> > For example: migrating from Debian to RHEL, or from RHEL4 to RHEL5?
> > The database is of course shutdown properly, and the PG major versions
> match.
> >
> > Or
Good
morning
You
have to revise the base folder to create postgres when you perform the
initial installation and verify the relation fallanado that I spend And
it turned out he had a folder in C: \ Program Files \ PostgreSQL \ 8.2 \
data \ base folder exists the number 1, this
is where the
=?iso-8859-1?Q?=22Martin_M=FCnstermann=22?= writes:
> In case it does not work great, what kind of problems would we experience?
In theory pg_control contains enough information to detect such
compatibility problems, so that you'd get a refusal to start.
In practice, maybe not, and the consequenc
At this moment we are considering a plan for upgrading many servers in our
datacenter.
As this is a very heterogeneous platform (from Oracle 10g, SQL Server 2008,
Firebird 2.1, Mysql 5, Postgre 8.4 up to Informix 5 and even COBOL apps) whe
are evaluating Virtualization or just sharing a server amon
Ramiro,
I don't know why virtualization is considered a no-no. We use VMware ESX.
On some smaller applications we run both the application and database on
the virutal machine. We've not had a issue with this combination in 5+
years. We also have 6 images that run on 2 machines just for th
Michael Gould wrote:
I don't know why virtualization is considered a no-no...Since these
are all quad core with 32 gig running Windows 2003 64 bit, we can run
about 100 users concurrently on each application server before we
start to see a strain.
You answered your own question here. Ram
Ramiro Barreca wrote:
1. Is there a configuration option we need to consider to share
this server?
The two main configuration options that impact how much RAM PostgreSQL
uses are shared_buffers and work_mem. If the server is shared, you just
need to avoid tuning those upwards as f
On Sun, Mar 28, 2010 at 16:27, Mike Williams wrote:
> Test are para-virt VMs with "regular" kernels, production are real
> machines with hardened kernels (grsec+pax).
Ive seen this error on a few boxes around here, using a non grsec
kernel fixes it. I never bothered to report it because I cant
r
15 matches
Mail list logo