"Struckhoff, Kevin" wrote:
> From: Kevin Grittner [mailto:kgri...@ymail.com]
>> "Struckhoff, Kevin" wrote:
>>> I've installed postgres 9.2 on a server, call it db01. I now want
>>> to access postgres from my app server, call it app01.
>>> It seems that something else is missing or needs to be d
Ok, the aplication server and your laptop have the IP adress in the same subnet
?
Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet
-Original Message-
From: "Struckhoff, Kevin"
Date: Wed, 10 Jul 2013 23:45:01
To: javmend...@gmail.com; Alvaro
Herrera;
pgsql-admi
Review the postgresql.conf and chek the "listen_adress" parameter.
listen_adress="localhost"
Change localhost by *
Example: listen_adress="*"
Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet
-Original Message-
From: Alvaro Herrera
Sender: pgsql-admin-owner@post
Struckhoff, Kevin wrote:
> I'm trying to use the psql tool:
>
> /home/postgres->psql test
> psql: could not connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
>
> the answer of course
I'm trying to use the psql tool:
/home/postgres->psql test
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
the answer of course is No..
Kevin Struckhoff, TDWI
Sr. IT M
Sorry, rhel 5.8. so there is a separate client install package?
Kevin Struckhoff, TDWI
Sr. IT Mgr, LA DR Operations
kstruckh...@ebay.comebayenterprise.com
o: 818.686.4719 | c: 818.968.0634 |
The information contained in this electronic mail transmission is intended only
for the use of
Struckhoff, Kevin wrote:
> Sorry, rhel 5.8. so there is a separate client install package?
Yes; on RHEL the library package is called postgresql-libs or something
similar, while the client package containing the psql utility is just
"postgresql". (The server lives in a package called postgresql-
"Struckhoff, Kevin" wrote:
> I've installed postgres 9.2 on a server, call it db01. I now want
> to access postgres from my app server, call it app01.
>
> What do I install on the app01 server? I've installed postgres
> 9.2 on it and set the postgresesql.conf file's listen_address to
> a value o
Struckhoff, Kevin wrote:
> I've installed postgres 9.2 on a server, call it db01. I now want to access
> postgres from my app server, call it app01.
>
> What do I install on the app01 server? I've installed postgres 9.2 on it and
> set the postgresesql.conf file's listen_address to a value of '*
I've installed postgres 9.2 on a server, call it db01. I now want to access
postgres from my app server, call it app01.
What do I install on the app01 server? I've installed postgres 9.2 on it and
set the postgresesql.conf file's listen_address to a value of '*' on both
machines. I've also modi
Following up to my earlier post: I have a master and a slave server (using
WAL), both 9.1. My 9.2 upgrade process is:
1) stop postgres on both servers
2) run pg_upgrade --link on both servers
3) change ports so 9.2 is on 5432, 9.1 on 5433
4) restart
Is this the best way to do it and ensure that t
On Wed, Jul 10, 2013 at 2:02 PM, k...@rice.edu wrote:
> On Wed, Jul 10, 2013 at 03:46:28PM -0500, lxnf9...@gmail.com wrote:
> > On Wed, 10 Jul 2013, Vincent Lau wrote:
> >
> > how would pg_upgrade be used to upgrade to a new machine
> > use nfs?
> > would i run pg_upgrade on the new server?
> >
>
On Wed, Jul 10, 2013 at 03:46:28PM -0500, lxnf9...@gmail.com wrote:
> On Wed, 10 Jul 2013, Vincent Lau wrote:
>
> how would pg_upgrade be used to upgrade to a new machine
> use nfs?
> would i run pg_upgrade on the new server?
>
>
I would replicate to the new server from the old using WAL to get
On Wed, 10 Jul 2013, Vincent Lau wrote:
On Wed, Jul 10, 2013 at 12:19 PM, Wells Oliver wrote:
OK, cool. I did not want to be in a position where I stop the servers,
pg_upgrade --link 9.1 to 9.2, then (eventually) pg_dropcluster of 9.1 and,
woops, I killed all of my data files.
And if you ha
On Wed, Jul 10, 2013 at 12:19 PM, Wells Oliver wrote:
> OK, cool. I did not want to be in a position where I stop the servers,
> pg_upgrade --link 9.1 to 9.2, then (eventually) pg_dropcluster of 9.1 and,
> woops, I killed all of my data files.
>
>
And if you have enough storage, you can always sta
OK, cool. I did not want to be in a position where I stop the servers,
pg_upgrade --link 9.1 to 9.2, then (eventually) pg_dropcluster of 9.1 and,
woops, I killed all of my data files.
On Wed, Jul 10, 2013 at 12:13 PM, k...@rice.edu wrote:
> On Wed, Jul 10, 2013 at 12:02:06PM -0700, Wells Oliver
On Wed, Jul 10, 2013 at 12:02:06PM -0700, Wells Oliver wrote:
> Hard linking means that you must maintain 8.2's data directory though, even
> after upgrade, correct? Since it's a link and not a copied file.
>
I think it only hard links the files to the new 9.2 data directory so you
can delete the
The -k or --link option makes hard links. Therefore, after the upgrade you
can safely wipe out the entire old 9.1 data directory. I removed the 8.4
data directory without affecting the 9.2 data. After pg_upgrade is
finished, it even generates a shell script called "delete_old_cluster.sh"
so you can
On Wed, Jul 10, 2013 at 11:52:54AM -0700, Wells Oliver wrote:
> Can anyone speak to the speed of pg_upgrade? Our database is 153GB. From
> 9.1 to 9.2, I'm nervous it might take hours. If it were less than hour,
> downtime would be more acceptable.
>
You can use the --link option and then you make
Hard linking means that you must maintain 8.2's data directory though, even
after upgrade, correct? Since it's a link and not a copied file.
On Wed, Jul 10, 2013 at 11:59 AM, Vincent Lau
wrote:
> We did an in-place upgrade(with the -k option) against a 6Tb DB from 8.4
> to 9.2. It took all of 10
We did an in-place upgrade(with the -k option) against a 6Tb DB from 8.4 to
9.2. It took all of 10 minutes to complete, which didn't count for running
the analyze afterward. However, if you are going to run the analyze DB
afterward, your mileage may vary.
On Wed, Jul 10, 2013 at 11:52 AM, Wells O
Can anyone speak to the speed of pg_upgrade? Our database is 153GB. From
9.1 to 9.2, I'm nervous it might take hours. If it were less than hour,
downtime would be more acceptable.
On Wed, Jul 10, 2013 at 11:08 AM, Jonathan Nalley wrote:
> On Wed, Jul 10, 2013 at 1:53 PM, Wells Oliver
> wrote:
>
On Wed, Jul 10, 2013 at 02:08:04PM -0400, Jonathan Nalley wrote:
> On Wed, Jul 10, 2013 at 1:53 PM, Wells Oliver wrote:
> > I have 9.1 running on 5432, and 9.2 running on 5433. The 9.1 database size
> > is 153g. 9.1 is actively used by systems, 9.2 is just sitting there empty.
> >
> > I'd like to
On 07/10/2013 11:53 AM, Wells Oliver wrote:
> I'd like to move the 9.1 database to 9.2 without any down time, and
> ensuring that no data is lost.
>
> My original idea was to make 9.2 a slave of 9.1, then switch it over.
You can't do this with streaming replication. But you can with slony.
Just
On Wed, Jul 10, 2013 at 1:53 PM, Wells Oliver wrote:
> I have 9.1 running on 5432, and 9.2 running on 5433. The 9.1 database size
> is 153g. 9.1 is actively used by systems, 9.2 is just sitting there empty.
>
> I'd like to move the 9.1 database to 9.2 without any down time, and ensuring
> that no
I have 9.1 running on 5432, and 9.2 running on 5433. The 9.1 database size
is 153g. 9.1 is actively used by systems, 9.2 is just sitting there empty.
I'd like to move the 9.1 database to 9.2 without any down time, and
ensuring that no data is lost.
My original idea was to make 9.2 a slave of 9.1,
Jerry Sievers writes:
> Kevin Grittner writes:
>> Jerry Sievers wrote:
>>> Planning to pg_upgrade some large (3TB) clusters using hard link
>>> method. Run time for the upgrade itself takes around 5 minutes.
>>> Unfortunately the post-upgrade analyze of the entire cluster is going
>>> to take a
Kevin Grittner writes:
> Jerry Sievers wrote:
>
>> Planning to pg_upgrade some large (3TB) clusters using hard link
>> method. Run time for the upgrade itself takes around 5 minutes.
>> Nice!! Origin version 8.4 and destination version 9.1.
>>
>> Unfortunately the post-upgrade analyze of the e
Jerry Sievers wrote:
> Planning to pg_upgrade some large (3TB) clusters using hard link
> method. Run time for the upgrade itself takes around 5 minutes.
> Nice!! Origin version 8.4 and destination version 9.1.
>
> Unfortunately the post-upgrade analyze of the entire cluster is going
> to take
29 matches
Mail list logo
