Thread: upgrade from FC9 / PG8.3 to C7 / PG 9.6 - utf8

I'm performing a long overdue upgrade of a Fedora 9 / Postgresql 8.3 to a 
Centos 7 / Postgresql 9.6 system.

I'm just going though the config files to check that everything is okay and 
I've found a discrepency regarding language settings.  I realise things have 
progressed a lot since 2008 when I built this server, so I wonder what is the 
right thing to do moving forward.  The old system has

# These settings are initialized by initdb, but they can be changed.
lc_messages = 'en_GB'    # locale for system error message  strings
lc_monetary = 'en_GB'    # locale for monetary formatting
lc_numeric = 'en_GB'    # locale for number formatting
lc_time = 'en_GB'        # locale for time formatting

while the new system has

lc_messages = 'en_GB.UTF-8'    # locale for system error message strings
lc_monetary = 'en_GB.UTF-8'    # locale for monetary formatting
lc_numeric = 'en_GB.UTF-8'    # locale for number formatting
lc_time = 'en_GB.UTF-8'        # locale for time formatting

Am I best changing the new system to match the old one?
If I leave the settings as they are, enabling the utf-8, how will it affect
    a) the pg_dumpall / pg_recover process
    b) using the database moving forward?

Gary

That is a very good question.

The honest answer is because the article(s) that I have been following have 
all pointed to 9.6.  Having installed 9.6 and imported my data a couple of 
times I've found it faultless.

Other than being on the latest version, what benefits and what problems would 
I encounter moving to 10.x?

If I were to go to 10.x on Centos 7, would I be able to install it alongside 
the existing 9.6 to test it? I have noticed with the 9.6 install that it's 
now using the version number as part of the data path.

As a side question, I will be moving PHP5 on my old box to PHP7 on my new one. 
Is there any gotcha's I need to worry about?

On Friday 18 January 2019 14:52:25 David Modica wrote:
> sorry, slightly off point but I am a newbie and I was wondering gary,
>
> why aren't you going to  postgresql 10.X  ? I keep thinking
>
> that I should stay as current as possible. should I relax about that ?
>
> david
>
> From: Scott Whitney <scott@journyx.com>
> Sent: Friday, January 18, 2019 9:31 AM
> To: Gary Stainburn <gary.stainburn@ringways.co.uk>; pgsql-admin
> <pgsql-admin@postgresql.org> Subject: Re: upgrade from FC9 / PG8.3 to C7 /
> PG 9.6 - utf8
>
>
> So long as you use pg_dump from PG 9 to dump the PG 8 databases, you'll be
> fine.
>
>
>
> en_GB.UTF-8 will be fine (and is probably preferred).
>
> ________________________________
> From: Gary Stainburn <gary.stainburn@ringways.co.uk>
> Sent: Friday, January 18, 2019 8:29 AM
> To: pgsql-admin
> Subject: upgrade from FC9 / PG8.3 to C7 / PG 9.6 - utf8
>
> I'm performing a long overdue upgrade of a Fedora 9 / Postgresql 8.3 to a
> Centos 7 / Postgresql 9.6 system.
>
> I'm just going though the config files to check that everything is okay and
> I've found a discrepency regarding language settings.  I realise things
> have progressed a lot since 2008 when I built this server, so I wonder what
> is the right thing to do moving forward.  The old system has
>
> # These settings are initialized by initdb, but they can be changed.
> lc_messages = 'en_GB'   # locale for system error message  strings
> lc_monetary = 'en_GB'   # locale for monetary formatting
> lc_numeric = 'en_GB'    # locale for number formatting
> lc_time = 'en_GB'               # locale for time formatting
>
> while the new system has
>
> lc_messages = 'en_GB.UTF-8'     # locale for system error message strings
> lc_monetary = 'en_GB.UTF-8'     # locale for monetary formatting
> lc_numeric = 'en_GB.UTF-8'      # locale for number formatting
> lc_time = 'en_GB.UTF-8'         # locale for time formatting
>
> Am I best changing the new system to match the old one?
> If I leave the settings as they are, enabling the utf-8, how will it affect
>         a) the pg_dumpall / pg_recover process
>         b) using the database moving forward?
>
> Gary
>
>
> [Image removed by sender.]
>
> [Image removed by sender.]<https://www.linkedin.com/company/journyx-inc/> 
> [Image removed by sender.] <https://www.twitter.com/journyxinc>
>
> [Image removed by sender.]
>
>
> Scott Whitney
> Director of IT
>
> [Image removed by sender.]
>
> scott@journyx.com<mailto:scott@journyx.com> | +1 (800) 755-9878
>
> 7600 Burnet Road, Ste. 300
> Austin, TX 78757
>
> Visit us at www.journyx.com<https://www.journyx.com/>
>
>
> To unsubscribe from Journyx promotional emails, click here
> <http://journyx.com/communication-preferences> or visit
> http://journyx.com/communication-preferences.



-- 
Gary Stainburn
Group I.T. Manager
Ringways Garages
http://www.ringways.co.uk 

On 18/1/19 5:08 μ.μ., Gary Stainburn wrote:
> That is a very good question.
>
> The honest answer is because the article(s) that I have been following have
> all pointed to 9.6.  Having installed 9.6 and imported my data a couple of
> times I've found it faultless.
>
> Other than being on the latest version, what benefits and what problems would
> I encounter moving to 10.x?
>
> If I were to go to 10.x on Centos 7, would I be able to install it alongside
> the existing 9.6 to test it? I have noticed with the 9.6 install that it's
> now using the version number as part of the data path.
9.6 is not page level compatible with e.g. 9.5 whereas 10.6 is with 10.5.
So in the versioning scheme PostreSQL community just dropped one dot.
Before (<=9*) it was x.y.z with all x.y.* being compatible whereas now (>=10*) it is x.y with all x.* being
compatible.
By compatible we mean that no pg_dump/restore or pg_upgrade is needed, just recompile and install.
>
> As a side question, I will be moving PHP5 on my old box to PHP7 on my new one.
> Is there any gotcha's I need to worry about?
>
> On Friday 18 January 2019 14:52:25 David Modica wrote:
>> sorry, slightly off point but I am a newbie and I was wondering gary,
>>
>> why aren't you going to  postgresql 10.X  ? I keep thinking
>>
>> that I should stay as current as possible. should I relax about that ?
>>
>> david
>>
>> From: Scott Whitney <scott@journyx.com>
>> Sent: Friday, January 18, 2019 9:31 AM
>> To: Gary Stainburn <gary.stainburn@ringways.co.uk>; pgsql-admin
>> <pgsql-admin@postgresql.org> Subject: Re: upgrade from FC9 / PG8.3 to C7 /
>> PG 9.6 - utf8
>>
>>
>> So long as you use pg_dump from PG 9 to dump the PG 8 databases, you'll be
>> fine.
>>
>>
>>
>> en_GB.UTF-8 will be fine (and is probably preferred).
>>
>> ________________________________
>> From: Gary Stainburn <gary.stainburn@ringways.co.uk>
>> Sent: Friday, January 18, 2019 8:29 AM
>> To: pgsql-admin
>> Subject: upgrade from FC9 / PG8.3 to C7 / PG 9.6 - utf8
>>
>> I'm performing a long overdue upgrade of a Fedora 9 / Postgresql 8.3 to a
>> Centos 7 / Postgresql 9.6 system.
>>
>> I'm just going though the config files to check that everything is okay and
>> I've found a discrepency regarding language settings.  I realise things
>> have progressed a lot since 2008 when I built this server, so I wonder what
>> is the right thing to do moving forward.  The old system has
>>
>> # These settings are initialized by initdb, but they can be changed.
>> lc_messages = 'en_GB'   # locale for system error message  strings
>> lc_monetary = 'en_GB'   # locale for monetary formatting
>> lc_numeric = 'en_GB'    # locale for number formatting
>> lc_time = 'en_GB'               # locale for time formatting
>>
>> while the new system has
>>
>> lc_messages = 'en_GB.UTF-8'     # locale for system error message strings
>> lc_monetary = 'en_GB.UTF-8'     # locale for monetary formatting
>> lc_numeric = 'en_GB.UTF-8'      # locale for number formatting
>> lc_time = 'en_GB.UTF-8'         # locale for time formatting
>>
>> Am I best changing the new system to match the old one?
>> If I leave the settings as they are, enabling the utf-8, how will it affect
>>          a) the pg_dumpall / pg_recover process
>>          b) using the database moving forward?
>>
>> Gary
>>
>>
>> [Image removed by sender.]
>>
>> [Image removed by sender.]<https://www.linkedin.com/company/journyx-inc/>
>> [Image removed by sender.] <https://www.twitter.com/journyxinc>
>>
>> [Image removed by sender.]
>>
>>
>> Scott Whitney
>> Director of IT
>>
>> [Image removed by sender.]
>>
>> scott@journyx.com<mailto:scott@journyx.com> | +1 (800) 755-9878
>>
>> 7600 Burnet Road, Ste. 300
>> Austin, TX 78757
>>
>> Visit us at www.journyx.com<https://www.journyx.com/>
>>
>>
>> To unsubscribe from Journyx promotional emails, click here
>> <http://journyx.com/communication-preferences> or visit
>> http://journyx.com/communication-preferences.
>
>


-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

On Friday 18 January 2019 15:18:45 Achilleas Mantzios wrote:
> On 18/1/19 5:08 μ.μ., Gary Stainburn wrote:
> > If I were to go to 10.x on Centos 7, would I be able to install it
> > alongside the existing 9.6 to test it? I have noticed with the 9.6
> > install that it's now using the version number as part of the data path.
>
> 9.6 is not page level compatible with e.g. 9.5 whereas 10.6 is with 10.5.
> So in the versioning scheme PostreSQL community just dropped one dot.
> Before (<=9*) it was x.y.z with all x.y.* being compatible whereas now
> (>=10*) it is x.y with all x.* being compatible. By compatible we mean that
> no pg_dump/restore or pg_upgrade is needed, just recompile and install.

I have installed 10.6, configured it and imported the data all without issue.
So far, so good.

I have done the import using the pg_dumpall done on the 8.3 system. From the
comments earlier, would I be better off doing a pg_dumpall of the 8.3 system
using the binarys from the 10.6 system?

On 18/1/19 5:30 μ.μ., Gary Stainburn wrote:
> On Friday 18 January 2019 15:18:45 Achilleas Mantzios wrote:
>> On 18/1/19 5:08 μ.μ., Gary Stainburn wrote:
>>> If I were to go to 10.x on Centos 7, would I be able to install it
>>> alongside the existing 9.6 to test it? I have noticed with the 9.6
>>> install that it's now using the version number as part of the data path.
>> 9.6 is not page level compatible with e.g. 9.5 whereas 10.6 is with 10.5.
>> So in the versioning scheme PostreSQL community just dropped one dot.
>> Before (<=9*) it was x.y.z with all x.y.* being compatible whereas now
>> (>=10*) it is x.y with all x.* being compatible. By compatible we mean that
>> no pg_dump/restore or pg_upgrade is needed, just recompile and install.
> I have installed 10.6, configured it and imported the data all without issue.
> So far, so good.
>
> I have done the import using the pg_dumpall done on the 8.3 system. From the
> comments earlier, would I be better off doing a pg_dumpall of the 8.3 system
> using the binarys from the 10.6 system?
That should work as well. The other way around is impossible.
>


-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

On 1/18/19 9:30 AM, Gary Stainburn wrote:
[snip]
> I have done the import using the pg_dumpall done on the 8.3 system. From the
> comments earlier, would I be better off doing a pg_dumpall of the 8.3 system
> using the binarys from the 10.6 system?

How much data do you have, and how large of a window do you have to migrate 
the data?

For example, we moved from 8.4 to 9.6 (that was frozen while 10 was still in 
beta) and it would have taken almost five days to dump the data using the 
single-threaded 8.4 pg_dump, and just as long to do a single-threaded restore.

OTOH, the elapsed time using the 9.6 pg_dump with 8 threads was 14 hours, 
and the restore only 8.33 hours.


-- 
Angular momentum makes the world go 'round.

On Friday 18 January 2019 16:23:25 Ron wrote:
> On 1/18/19 9:30 AM, Gary Stainburn wrote:
> [snip]
>
> > I have done the import using the pg_dumpall done on the 8.3 system. From
> > the comments earlier, would I be better off doing a pg_dumpall of the 8.3
> > system using the binarys from the 10.6 system?
>
> How much data do you have, and how large of a window do you have to migrate
> the data?
>
> For example, we moved from 8.4 to 9.6 (that was frozen while 10 was still
> in beta) and it would have taken almost five days to dump the data using
> the single-threaded 8.4 pg_dump, and just as long to do a single-threaded
> restore.
>
> OTOH, the elapsed time using the 9.6 pg_dump with 8 threads was 14 hours,
> and the restore only 8.33 hours.
My data is nowhere near that scale. Mine took less than 40 minutes to run 
pg_dumpall even using thr 8.3 pg_dumpall.

I have just had a look at the output from the 10.6 import and I am seeing a 
large number of errors like:

psql:2019-01-18_1556.sql:8918192: ERROR:  could not access 
file "$libdir/pgcrypto": No such file or directory
psql:2019-01-18_1556.sql:8918195: ERROR:  function 
public.pgp_sym_encrypt(text, text, text) does not exist


Anyone know why I'm getting this and what I need to do to fix it? I wasn't 
getting this (AFAIK) when importing to 9.6

On Friday 18 January 2019 16:42:45 Gary Stainburn wrote:
> My data is nowhere near that scale. Mine took less than 40 minutes to run
> pg_dumpall even using thr 8.3 pg_dumpall.
>
> I have just had a look at the output from the 10.6 import and I am seeing a
> large number of errors like:
>
> psql:2019-01-18_1556.sql:8918192: ERROR:  could not access
> file "$libdir/pgcrypto": No such file or directory
> psql:2019-01-18_1556.sql:8918195: ERROR:  function
> public.pgp_sym_encrypt(text, text, text) does not exist
>
>
> Anyone know why I'm getting this and what I need to do to fix it? I wasn't
> getting this (AFAIK) when importing to 9.6

I found that I was getting this error because I had missed out installing the 
postgresql10-contrib-10.6-1PGDG.rhel7.x86_64 RPM.

After doing this the install worked perfectly. However, when I try to use the 
crypt() function I get the following error.  I can't see what I've missed

users=# select crypt('password','myhash');
ERROR:  function crypt(unknown, unknown) does not exist
LINE 1: select crypt('password','myhash');
               ^
HINT:  No function matches the given name and argument types. You might need 
to add explicit type casts.
users=# 


I've got the following RPM's installed:

postgresql10-libs-10.6-1PGDG.rhel7.x86_64
postgresql10-contrib-10.6-1PGDG.rhel7.x86_64
postgresql10-10.6-1PGDG.rhel7.x86_64
postgresql10-server-10.6-1PGDG.rhel7.x86_64

On Monday 21 January 2019 15:03:23 Gary Stainburn wrote:
> After doing this the install worked perfectly. However, when I try to use
> the crypt() function I get the following error.  I can't see what I've
> missed
>
> users=# select crypt('password','myhash');
> ERROR:  function crypt(unknown, unknown) does not exist
> LINE 1: select crypt('password','myhash');
>                ^
> HINT:  No function matches the given name and argument types. You might
> need to add explicit type casts.
> users=#


Sory folks, just found the answer.  I need to run 

create extension pgcrypto;

in each of my databases