[GENERAL] strange connection problem.

[Day, David]

I have a development site ( FreeBSD 10.1 and Postgres 9.3 )  where I can 
connect to the database via psql or pgadminIII both locally and remotely.
However, all of the local apps ( 3 different ones )  that would connect to it 
are failing to  connect.

I see no error events in the messages/postgres log files related to bad 
attempts.
I suspect something with name resolution,
The hosts, hosts.conf and resolv.conf files are set to resolv first via the 
hosts file
And the hostname and localhost are properly defined there.

The site installation did have some initial DNS setup issues.  However this 
command works fine locally.
"psql -U   -h  database.
i.e. name resolution works locally fine for psql.

The problem does not go away on shutting down and starting up the system ( 
Virtual Machine )

Is there anything on the postgres side that might explain this situation ?

Will likely re-install and see if the problem goes away. ( build of the day 
problem ? )
It is an interesting puzzle at the moment.



Thanks


Dave

Re: [GENERAL] strange connection problem.

[Yves Dorfsman]

On 2015-10-23 08:29, Day, David wrote:
> I have a development site ( FreeBSD 10.1 and Postgres 9.3 )  where I can
> connect to the database via psql or pgadminIII both locally and remotely.
> 
> However, all of the local apps ( 3 different ones )  that would connect to it
> are failing to  connect.

Sounds like your apps are using a different port than the default install. Use
"psql -p " with the port from the URI configured in your apps.


-- 
http://yves.zioup.com
gpg: 4096R/32B0F416



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] strange connection problem.

[David G. Johnston]

On Fri, Oct 23, 2015 at 10:29 AM, Day, David  wrote:

> I have a development site ( FreeBSD 10.1 and Postgres 9.3 )  where I can
> connect to the database via psql or pgadminIII both locally and remotely.
>
> However, all of the local apps ( 3 different ones )  that would connect to
> it are failing to  connect.
>

​So how do the methods the local apps use to connect to PostgreSQL differ
compared to running psql directly on the same machine?

David J.
​

Re: [GENERAL] strange connection problem.

[Adrian Klaver]

On 10/23/2015 07:29 AM, Day, David wrote:

I have a development site ( FreeBSD 10.1 and Postgres 9.3 )  where I can
connect to the database via psql or pgadminIII both locally and remotely.

However, all of the local apps ( 3 different ones )  that would connect
to it are failing to  connect.

I see no error events in the messages/postgres log files related to bad
attempts.

I suspect something with name resolution,

The hosts, hosts.conf and resolv.conf files are set to resolv first via
the hosts file

And the hostname and localhost are properly defined there.

The site installation did have some initial DNS setup issues.  However
this command works fine locally.

“psql –U   -h  database.

i.e. name resolution works locally fine for psql.

The problem does not go away on shutting down and starting up the system
( Virtual Machine )

Is there anything on the postgres side that might explain this situation ?


What are the connection parameters for the local apps versus the ones 
you used above for psql?


In particular the user?

What is in your pg_hba.conf file?

When you say locally are you talking about everything happening in the 
VM or between the host machine and the VM or some combination thereof?


What are your logging parameters in postgresql.conf?



Will likely re-install and see if the problem goes away. ( build of the
day problem ? )

It is an interesting puzzle at the moment.

Thanks

Dave




--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] clone_schema function

[Melvin Davidson]

Good catch. Thank you very much!

On Fri, Oct 23, 2015 at 10:50 AM, Predrag Maric  wrote:

> The script is generating foreign keys which reference tables in the source
> schema.
> I had to change
>
> 219SELECT 'ALTER TABLE ' || quote_ident(dest_schema) || '.' ||
> quote_ident(rn.relname)
> 220  || ' ADD CONSTRAINT ' ||
> quote_ident(ct.conname) || ' ' || pg_get_constraintdef(ct.oid) || ';'
>
> to
>
> 219SELECT 'ALTER TABLE ' || quote_ident(dest_schema) || '.' ||
> quote_ident(rn.relname)
> 220 || ' ADD CONSTRAINT ' ||
> quote_ident(ct.conname) || ' ' || replace(pg_get_constraintdef(ct.oid),
> quote_ident(source_schema) || '.', quote_ident(dest_schema) || '.') || ';'
>
> I'm attaching the updated script.
>



-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] strange connection problem.

[Day, David]

One app is connecting through libpqxx,  the other 2,  glassfish and ejabber 
chat agent,  I am not certain.
It is only on this one machine where I am having a connection  issue with any 
of these apps.
I can connect via the identical roles that these apps would be using via the 
psql command line on this system.
I doubt that all three would have a connection issue on the same day, without 
some kind of global matter.

My pg_hba.conf file on this system is the following.
# "local" is for Unix domain socket connections only
local   all all trust
# IPv4 local connections:
hostall all 127.0.0.1/32trust
# IPv6 local connections:
hostall all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
host all all 192.168.32.0/19 trust

I don’t believe this to be a postgres problem, but you don’t know what you 
don’t know.




From: David G. Johnston [mailto:david.g.johns...@gmail.com]
Sent: Friday, October 23, 2015 10:36 AM
To: Day, David
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] strange connection problem.

On Fri, Oct 23, 2015 at 10:29 AM, Day, David 
mailto:d...@redcom.com>> wrote:
I have a development site ( FreeBSD 10.1 and Postgres 9.3 )  where I can 
connect to the database via psql or pgadminIII both locally and remotely.
However, all of the local apps ( 3 different ones )  that would connect to it 
are failing to  connect.

​So how do the methods the local apps use to connect to PostgreSQL differ 
compared to running psql directly on the same machine?

David J.
​

Re: [GENERAL] A question about PL/pgSQL DECLAREd variable behavior

[Jim Nasby]

On 10/22/15 8:52 PM, Dane Foster wrote:

It just occurred to me that another option, for my specific example,
would be to record/cache FOUND instead of testing the RECORD variable
for its NULLness. Unless of course assigning FOUND to a variable is a
pass-by-reference assignment, which in the actual code that I'm writing
would be problematic because FOUND is set many times because there are
at least 4 SQL commands that my function executes.


AFAIK, functions don't really do pass by reference, except for INOUT 
parameters. In any case, FOUND is definitely reset when you do things 
like SELECT INTO.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] A question about PL/pgSQL DECLAREd variable behavior

[Pavel Stehule]

2015-10-23 18:05 GMT+02:00 Jim Nasby :

> On 10/22/15 8:52 PM, Dane Foster wrote:
>
>> It just occurred to me that another option, for my specific example,
>> would be to record/cache FOUND instead of testing the RECORD variable
>> for its NULLness. Unless of course assigning FOUND to a variable is a
>> pass-by-reference assignment, which in the actual code that I'm writing
>> would be problematic because FOUND is set many times because there are
>> at least 4 SQL commands that my function executes.
>>
>
> AFAIK, functions don't really do pass by reference, except for INOUT
> parameters. In any case, FOUND is definitely reset when you do things like
> SELECT INTO.
>

Anytime parameters are passed by value. OUT variables are emulated via
dynamic composite types. After execution of any SQL statement is FOUND
variable refreshed.

Regards

Pavel


> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: [GENERAL] strange connection problem.

[Tom Lane]

"Day, David"  writes:
> I have a development site ( FreeBSD 10.1 and Postgres 9.3 )  where I can 
> connect to the database via psql or pgadminIII both locally and remotely.
> However, all of the local apps ( 3 different ones )  that would connect to it 
> are failing to  connect.

Are those apps trying to use TCP connections, or Unix-socket connections?
If the latter, it might be a discrepancy in where they expect the socket
file to be versus where the postmaster thinks it should be.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] strange connection problem.

[Adrian Klaver]

On 10/23/2015 08:23 AM, Day, David wrote:

One app is connecting through libpqxx,  the other 2,  glassfish and
ejabber chat agent,  I am not certain.

It is only on this one machine where I am having a connection  issue
with any of these apps.

I can connect via the identical roles that these apps would be using via
the psql command line on this system.

I doubt that all three would have a connection issue on the same day,
without some kind of global matter.

My pg_hba.conf file on this system is the following.

# "local" is for Unix domain socket connections only

local   all all trust

# IPv4 local connections:

hostall all 127.0.0.1/32trust

# IPv6 local connections:

hostall all ::1/128 trust

# Allow replication connections from localhost, by a user with the

# replication privilege.

host all all 192.168.32.0/19 trust

I don’t believe this to be a postgres problem, but you don’t know what
you don’t know.




Can you launch one or more of the apps from the command line and see if 
any errors appear there, that are not bubbling up to the app?


Also, and to answer Toms questions, what are the exact connection 
parameters being used in the app(s)?




--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] strange connection problem.

[Day, David]

I figured this out and it is not a Postgres issue.
There was a area  of initialization overlooked by the installer on a fresh 
install
of a development system..

I had to add a little extra debug to see that one key job not
only was not getting attached to the database, it was not even trying.
After seeing that I able to run down the installation flaws.

Thanks very much to all for your suggestions on this matter.


Regards


Dave



-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us] 
Sent: Friday, October 23, 2015 12:49 PM
To: Day, David
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] strange connection problem.

"Day, David"  writes:
> I have a development site ( FreeBSD 10.1 and Postgres 9.3 )  where I can 
> connect to the database via psql or pgadminIII both locally and remotely.
> However, all of the local apps ( 3 different ones )  that would connect to it 
> are failing to  connect.

Are those apps trying to use TCP connections, or Unix-socket connections?
If the latter, it might be a discrepancy in where they expect the socket file 
to be versus where the postmaster thinks it should be.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] clone_schema function

[Predrag Maric]

The script is generating foreign keys which reference tables in the source
schema.
I had to change

219SELECT 'ALTER TABLE ' || quote_ident(dest_schema) || '.' ||
quote_ident(rn.relname)
220  || ' ADD CONSTRAINT ' ||
quote_ident(ct.conname) || ' ' || pg_get_constraintdef(ct.oid) || ';'

to

219SELECT 'ALTER TABLE ' || quote_ident(dest_schema) || '.' ||
quote_ident(rn.relname)
220 || ' ADD CONSTRAINT ' ||
quote_ident(ct.conname) || ' ' || replace(pg_get_constraintdef(ct.oid),
quote_ident(source_schema) || '.', quote_ident(dest_schema) || '.') || ';'

I'm attaching the updated script.
-- Function: clone_schema(text, text, boolean)

-- DROP FUNCTION clone_schema(text, text, boolean);

CREATE OR REPLACE FUNCTION clone_schema(
source_schema text,
dest_schema text,
include_recs boolean)
  RETURNS void AS
$BODY$
--  Initial code by Emanuel '3manuek' 
--  Last revision 2015-09-20 by Melvin Davidson
--  This function will clone all sequences, tables, indexes, rules, triggers, 
--  data(optional), views & functions from any existing schema to a new schema
-- SAMPLE CALL:
-- SELECT clone_schema('public', 'new_schema', TRUE);

DECLARE
  src_oid  oid;
  tbl_oid  oid;
  func_oid oid;
  con_oid  oid;
  v_path   text;
  v_func   text;
  v_args   text;
  v_connametext;
  v_rule   text;
  v_trig   text;
  object   text;
  buffer   text;
  srctbl   text;
  default_ text;
  v_column text;
  qry  text;
  dest_qry text;
  v_deftext;
  v_stat   integer;
  seqval   bigint;
  sq_last_valuebigint;
  sq_max_value bigint;
  sq_start_value   bigint;
  sq_increment_by  bigint;
  sq_min_value bigint;
  sq_cache_value   bigint;
  sq_log_cnt   bigint;
  sq_is_called boolean;
  sq_is_cycled boolean;
  sq_cycledchar(10);

BEGIN

-- Check that source_schema exists
  SELECT oid INTO src_oid
FROM pg_namespace
   WHERE nspname = quote_ident(source_schema);
  IF NOT FOUND
THEN 
RAISE NOTICE 'source schema % does not exist!', source_schema;
RETURN ;
  END IF;

  -- Check that dest_schema does not yet exist
  PERFORM nspname 
FROM pg_namespace
   WHERE nspname = quote_ident(dest_schema);
  IF FOUND
THEN 
RAISE NOTICE 'dest schema % already exists!', dest_schema;
RETURN ;
  END IF;

  EXECUTE 'CREATE SCHEMA ' || quote_ident(dest_schema) ;

  -- Add schema comment
  SELECT description INTO v_def
FROM pg_description
   WHERE objoid = src_oid
   AND objsubid = 0;
  IF FOUND 
THEN 
  EXECUTE 'COMMENT ON SCHEMA ' || quote_ident(dest_schema) || ' IS ' || 
quote_literal(v_def);
  END IF;
  
  -- Create sequences
  -- TODO: Find a way to make this sequence's owner is the correct table.
  FOR object IN
SELECT sequence_name::text 
  FROM information_schema.sequences
 WHERE sequence_schema = quote_ident(source_schema)
  LOOP
EXECUTE 'CREATE SEQUENCE ' || quote_ident(dest_schema) || '.' || 
quote_ident(object);
srctbl := quote_ident(source_schema) || '.' || quote_ident(object);

EXECUTE 'SELECT last_value, max_value, start_value, increment_by, 
min_value, cache_value, log_cnt, is_cycled, is_called 
  FROM ' || quote_ident(source_schema) || '.' || 
quote_ident(object) || ';' 
  INTO sq_last_value, sq_max_value, sq_start_value, 
sq_increment_by, sq_min_value, sq_cache_value, sq_log_cnt, sq_is_cycled, 
sq_is_called ; 

IF sq_is_cycled 
  THEN 
sq_cycled := 'CYCLE';
ELSE
sq_cycled := 'NO CYCLE';
END IF;

EXECUTE 'ALTER SEQUENCE '   || quote_ident(dest_schema) || '.' || 
quote_ident(object) 
|| ' INCREMENT BY ' || sq_increment_by
|| ' MINVALUE ' || sq_min_value 
|| ' MAXVALUE ' || sq_max_value
|| ' START WITH '   || sq_start_value
|| ' RESTART '  || sq_min_value 
|| ' CACHE '|| sq_cache_value 
|| sq_cycled || ' ;' ;

buffer := quote_ident(dest_schema) || '.' || quote_ident(object);
IF include_recs 
THEN
EXECUTE 'SELECT setval( ''' || buffer || ''', ' || sq_last_value || 
', ' || sq_is_called || ');' ; 
ELSE
EXECUTE 'SELECT setval( ''' || buffer || ''', ' || sq_start_value 
|| ', ' || sq_is_called || ');' ;
END IF;

  -- add sequence comments
SELECT oid INTO tbl_oid
  FROM pg_class 
 WHERE relkind = 'S'
   AND relnamespace = src_oid
   AND relname = quote_ident(object);

SELECT description INTO v_def
  FROM pg_description
 WHERE objoid = tbl_oid
   AND objsubid = 0;

IF FOUND
  THEN  
EXECUTE 'COMMENT ON SEQUENCE ' || quote_ident(dest_schema) || '.' || 
quote_ident(object)
 || ' IS ''' || v_def || ''';';
END IF;


  END LOOP;

-- Create tables 
  FO

Fwd: [GENERAL] trouble downloading postgres 9.4 for RHEL 6.x

[anj patnaik]

Hello all,


I got past the yum install, ran initdb but running into errors when
starting service. Do you have to login as user postgres to start the
service? THANKS

I am on RHEL 6.5 and don't know the postgres user password.

 service postgresql9.4 start
postgresql9.4: unrecognized service
-bash-4.1$  service postgresql start
postgresql: unrecognized service
-bash-4.1$ sudo passwd postgres
[sudo] password for postgres:
Sorry, try again.
[sudo] password for postgres:
Sorry, try again.
[sudo] password for postgres:
sudo: 2 incorrect password attempts
-bash-4.1$  service postgresql-9.4 restart
Stopping postgresql-9.4 service:   [  OK  ]
Starting postgresql-9.4 service:   [FAILED]
-bash-4.1$ vi /var/lib/pgsql/9.4/pgstartup.log


On Thu, Oct 22, 2015 at 4:11 PM, Adrian Klaver 
wrote:

> On 10/22/2015 01:05 PM, anj patnaik wrote:
>
>> bash-4.1$ sudo yum install
>>
>> http://yum.postgresql.org/9.4/redhat/rhel-6-x86_64/pgdg-redhat94-9.4-1.noarch.rpm
>> Loaded plugins: security
>> Setting up Install Process
>> pgdg-redhat94-9.4-1.noarch.rpm
>>  | 5.2 kB 00:00
>> Examining /var/tmp/yum-root-Ni6saZ/pgdg-redhat94-9.4-1.noarch.rpm:
>> pgdg-redhat94-9.4-1.noarch
>> /var/tmp/yum-root-Ni6saZ/pgdg-redhat94-9.4-1.noarch.rpm: does not update
>> installed package.
>> Error: Nothing to do
>>
>
> Looks to me("Loaded plugins: security") there is something monitoring
> downloads on you machine. Given that this is RedHat I would say SELinux.
> Might be why the installer failed. In any case I do not use RedHat so I am
> not much use here. Try what I suggest below and if that does not work I
> would re-post to list with the above as there are people there that know
> more about RedHat then I and will have the knowledge to get the install to
> work.
>
> That is first step. Now go to next step:
>
> http://www.postgresql.org/download/linux/redhat/
> "
> Once this is done, you can proceed to install and update packages the same
> way as the ones included in the distribution.
>
> yum install postgresql94-server postgresql94-contrib
> service postgresql-9.4 initdb
> chkconfig postgresql-9.4 on "
>
>
>>
>> On Thu, Oct 22, 2015 at 3:08 PM, Adrian Klaver
>> mailto:adrian.kla...@aklaver.com>> wrote:
>>
>> On 10/22/2015 12:03 PM, anj patnaik wrote:
>>
>> bash-4.1$ chmod 755 postgresql-9.5.0-beta1-linux-x64.run.1
>> bash-4.1$ ./postgresql-9.5.0-beta1-linux-x64.run.1
>> bash-4.1$ sudo ./postgresql-9.5.0-beta1-linux-x64.run.1
>> [sudo] password for apatnaik:
>> Installer payload initialization failed. This is likely due to an
>> incomplete or corrupt downloaded file.
>>
>>
>> Does it work for you? Can you let me know?
>>
>>
>> Yes, it works for me. I am not on RedHat though. At this point just
>> do the yum install, it is the better option anyway.
>>
>>
>> Thanks
>>
>> On Thu, Oct 22, 2015 at 2:56 PM, Adrian Klaver
>> mailto:adrian.kla...@aklaver.com>
>> >
>> >> wrote:
>>
>>  On 10/22/2015 10:03 AM, anj patnaik wrote:
>>
>>  Adrian,
>>  I am doing same steps as you. And my byte count matches
>> yours.
>>  It is a
>>  RHEL 6.5 Linux machine. If the byte count matches how
>> can it be
>>  incomplete? I am baffled. Thanks for any clues!
>>
>>  bash-4.1$ ls -all
>>  total 132452
>>
>>  -rwxrwxrwx  1 apatnaik oprofile 37659362 Oct 20 20:41
>>  postgresql-9.4.4-3-linux-x64.run
>>  -rw-r-  1 apatnaik oprofile 37548416 Oct 22 12:51
>>  postgresql-9.5.0-beta1-linux-x64.run
>>  bash-4.1$ chmod 755 postgresql-9.5.0-beta1-linux-x64.run
>>  bash-4.1$  sudo ./postgresql-9.5.0-beta1-linux-x64.run
>>  [sudo] password for apatnaik:
>>
>>  Installer payload initialization failed. This is likely
>> due to an
>>  incomplete or corrupt downloaded file
>>
>>
>>
>>  If you are dead set on using the installer you might try,
>> from
>>  command line:
>>
>>  wget
>>
>> http://get.enterprisedb.com/postgresql/postgresql-9.5.0-beta1-linux-x64.run
>>
>>  See if the direct download does any better.
>>
>>  --
>>  Adrian Klaver
>> adrian.kla...@aklaver.com 
>> > >
>>
>>
>>
>>
>> --
>> Adrian Klaver
>> adrian.kla...@aklaver.com 
>>
>>
>>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

Re: Fwd: [GENERAL] trouble downloading postgres 9.4 for RHEL 6.x

[Adrian Klaver]

On 10/23/2015 11:45 AM, anj patnaik wrote:

Hello all,


I got past the yum install, ran initdb but running into errors when
starting service. Do you have to login as user postgres to start the
service? THANKS

I am on RHEL 6.5 and don't know the postgres user password.



Off-list message indicated this was solved.


--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] question

[Adrian Klaver]

On 10/23/2015 03:22 PM, anj patnaik wrote:

Quick update on the above:

1) I got past the password prompt by changing the pg_hba.conf on target
machine to trust.

2) I am still running this command to restore on remote machine and want
feedback as it appears to NOT create the desired table:

xzcat dump_xz |/opt/PostgreSQL/9.4/bin/psql -h mycomp.com
 postgres -U postgres


I do not see that working for the reason below:

/pg_dump -t RECORDER  -Fc postgres -Z0 | xz -9 > /tmp/dump_xz

http://www.postgresql.org/docs/9.4/interactive/app-pgdump.html
"
F format
--format=format

Selects the format of the output. format can be one of the following:

p
plain

Output a plain-text SQL script file (the default).
c
custom

Output a custom-format archive suitable for input into 
pg_restore. Together with the directory output format, this is the most 
flexible output format in that it allows manual selection and reordering 
of archived items during restore. This format is also compressed by 
default. "



In particular- 'Output a custom-format archive suitable for input into 
pg_restore. '


psql will not know what to do with this.





Thanks.


On Fri, Oct 23, 2015 at 6:07 PM, anj patnaik mailto:patn...@gmail.com>> wrote:

Thanks Adrian. I've got postgres 9.4 running on a second RHEL 6.5
machine. This is the machine I want to restore the pg_dump to.

Last week, I ran this command on the main PG 9.4 db server:

./pg_dump -t RECORDER  -Fc postgres -Z0 | xz -9 > /tmp/dump_xz

The -Z0 turns off compression. So I used xz and noticed the file was
not that big.

Now, I got PG 9.4 running today on a 2nd machine. I just did the
initdb, started service, updated the hba.conf and postgres.conf to
accept connections from the outside and then restarted service.

1) When i attempt to restore the archived, I get an error to provide
password and I am confused what to do here.

2) is it correct to do xzcat and then pipe that to pgsl? I want to
restore on mymachine.com 

3) on the target machine, I ran initdb and by default it creates
postgres. Will that be a problem when restoring?

On this machine I am connected as root.

xzcat dump_xz |/opt/PostgreSQL/9.4/bin/psql -h mymachine.com
 postgres
Password:


Thank you!

On Sat, Oct 17, 2015 at 7:42 AM, Francisco Olarte
mailto:fola...@peoplecall.com>> wrote:

Hi Anj:

On Sat, Oct 17, 2015 at 3:11 AM, anj patnaik mailto:patn...@gmail.com>> wrote:
> My question is for Francisco who replied regarding xz. I was curious 
what
> options he used. Thanks.

1st, we do not normally top post on this list.

Second, I do not remember the exact options I use. I can look
them up,
but they are going to be surely useless ( they are for a custom
process with does several things with files, it uses gzip ( in Fc
backups ), plus xz ( for some files which need to be kept for a long
time and are nearly never needed ), plus lzo ( as I found lzo
compressed temporary files were faster than uncompressed ones ),
and a
lot of code. But in the development process we did a full comparison
of several compressor, and found what I stated with bzip2, it was
surpassed in every combination of options by xz ( plain bzip2, plain
xz ).

Francisco Olarte.






--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general