problem with self built postgres 9.0.9

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

problem with self built postgres 9.0.9

Gabriele Bulfon
Hi, I had to build postgres 9.0.9 from sources to run it under our new XStreamOS/illumos release.
It used to build and run without problems in previous releases.
 
On this, just by running initdb I get these errors:

sonicle@xstorage1:/sonicle$ initdb -D /sonicle/pgdata
The files belonging to this database system will be owned by user "sonicle".
This user must also own the server process.

The database cluster will be initialized with locale en_US.UTF-8.
The default database encoding has accordingly been set to UTF8.
The default text search configuration will be set to "english".

creating directory /sonicle/pgdata ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 32MB
creating configuration files ... ok
creating template1 database in /sonicle/pgdata/base/1 ... ok
initializing pg_authid ... FATAL: column is not in index
child process exited with exit code 1
initdb: removing data directory "/sonicle/pgdata"
 
Even running postgres over an already previously populated pgdata, any attempt to connect to the database results in "FATAL: column is not in index".
 
Any idea where the problem may be?
 
Thanks!
Gabriele

Reply | Threaded
Open this post in threaded view
|

Re: problem with self built postgres 9.0.9

Adrian Klaver-4
On 5/29/20 6:32 AM, Gabriele Bulfon wrote:
> Hi, I had to build postgres 9.0.9 from sources to run it under our new
> XStreamOS/illumos release.

First 9.0 is ~ 5 years past EOL and it ended at 9.0.23.

Second this is as close as I could come to a solution:

https://www.postgresql.org/message-id/17948.1365090217%40sss.pgh.pa.us

Given that you say you are building against a new OS release I would
look at what changed in the development stack.


> It used to build and run without problems in previous releases.
> On this, just by running initdb I get these errors:
>
> sonicle@xstorage1:/sonicle$ initdb -D /sonicle/pgdata
> The files belonging to this database system will be owned by user "sonicle".
> This user must also own the server process.
>
> The database cluster will be initialized with locale en_US.UTF-8.
> The default database encoding has accordingly been set to UTF8.
> The default text search configuration will be set to "english".
>
> creating directory /sonicle/pgdata ... ok
> creating subdirectories ... ok
> selecting default max_connections ... 100
> selecting default shared_buffers ... 32MB
> creating configuration files ... ok
> creating template1 database in /sonicle/pgdata/base/1 ... ok
> initializing pg_authid ... FATAL: column is not in index
> child process exited with exit code 1
> initdb: removing data directory "/sonicle/pgdata"
> Even running postgres over an already previously populated pgdata, any
> attempt to connect to the database results in "FATAL: column is not in
> index".
> Any idea where the problem may be?
> Thanks!
> Gabriele
>
> *Sonicle S.r.l. *: http://www.sonicle.com <http://www.sonicle.com/>
> *Music: *http://www.gabrielebulfon.com <http://www.gabrielebulfon.com/>
> *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon


--
Adrian Klaver
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: problem with self built postgres 9.0.9

Gabriele Bulfon
Amazing! Rebuilt without -O and it worked like a charm!
Thanks, at the moment I need to stick to 9.0.9 on this machine to be able to reuse the same database files.
 
Thanks!

Gabriele




----------------------------------------------------------------------------------

Da: Adrian Klaver <[hidden email]>
A: Gabriele Bulfon <[hidden email]> [hidden email]
Data: 29 maggio 2020 15.45.32 CEST
Oggetto: Re: problem with self built postgres 9.0.9

On 5/29/20 6:32 AM, Gabriele Bulfon wrote:
> Hi, I had to build postgres 9.0.9 from sources to run it under our new
> XStreamOS/illumos release.

First 9.0 is ~ 5 years past EOL and it ended at 9.0.23.

Second this is as close as I could come to a solution:

https://www.postgresql.org/message-id/17948.1365090217%40sss.pgh.pa.us

Given that you say you are building against a new OS release I would
look at what changed in the development stack.


> It used to build and run without problems in previous releases.
> On this, just by running initdb I get these errors:
>
> sonicle@xstorage1:/sonicle$ initdb -D /sonicle/pgdata
> The files belonging to this database system will be owned by user "sonicle".
> This user must also own the server process.
>
> The database cluster will be initialized with locale en_US.UTF-8.
> The default database encoding has accordingly been set to UTF8.
> The default text search configuration will be set to "english".
>
> creating directory /sonicle/pgdata ... ok
> creating subdirectories ... ok
> selecting default max_connections ... 100
> selecting default shared_buffers ... 32MB
> creating configuration files ... ok
> creating template1 database in /sonicle/pgdata/base/1 ... ok
> initializing pg_authid ... FATAL: column is not in index
> child process exited with exit code 1
> initdb: removing data directory "/sonicle/pgdata"
> Even running postgres over an already previously populated pgdata, any
> attempt to connect to the database results in "FATAL: column is not in
> index".
> Any idea where the problem may be?
> Thanks!
> Gabriele
>
> *Sonicle S.r.l. *: http://www.sonicle.com <http://www.sonicle.com/>
> *Music: *http://www.gabrielebulfon.com <http://www.gabrielebulfon.com/>
> *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon


--
Adrian Klaver
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: problem with self built postgres 9.0.9

David G Johnston
On Fri, May 29, 2020 at 7:08 AM Gabriele Bulfon <[hidden email]> wrote:
Amazing! Rebuilt without -O and it worked like a charm!
Thanks, at the moment I need to stick to 9.0.9 on this machine to be able to reuse the same database files.


Just to be thorough.  You can update to 9.0.23 (i.e., build against the tip of the 9.0.x set of branches) and still use the same database files.  For all versions (starting with v10 the version has only two components, not three) changing the final digit in the version is a code-only change.

There is no material difference to risk for building 9.0.23 against the newer O/S and compiler, etc, than it is to build 9.0.9 against the newer O/S and compiler, etc.  You assumed basically maximum risk when you choose to keep using version 9.0 and upgraded everything else around it to versions that were possibly never tested against it - and if they were tested it is more likely they were tested against 9.0.23 as it is years more current.

David J.

Reply | Threaded
Open this post in threaded view
|

Re: problem with self built postgres 9.0.9

Tom Lane-2
In reply to this post by Gabriele Bulfon
Gabriele Bulfon <[hidden email]> writes:
> Amazing! Rebuilt without -O and it worked like a charm!

Yeah, modern compilers tend to apply optimizations that break old versions
of Postgres.  -O0 usually takes care of it.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: problem with self built postgres 9.0.9

Gabriele Bulfon
In reply to this post by David G Johnston
I will consider the upgrade, thanks a lot!

Gabriele





Da: David G. Johnston <[hidden email]>
A: Gabriele Bulfon <[hidden email]>
Cc: Adrian Klaver <[hidden email]>pgsql-generallists.postgresql.org <[hidden email]>
Data: 29 maggio 2020 16.18.44 CEST
Oggetto: Re: problem with self built postgres 9.0.9


On Fri, May 29, 2020 at 7:08 AM Gabriele Bulfon <[hidden email]> wrote:
Amazing! Rebuilt without -O and it worked like a charm!
Thanks, at the moment I need to stick to 9.0.9 on this machine to be able to reuse the same database files.
 
 
Just to be thorough.  You can update to 9.0.23 (i.e., build against the tip of the 9.0.x set of branches) and still use the same database files.  For all versions (starting with v10 the version has only two components, not three) changing the final digit in the version is a code-only change.
 
There is no material difference to risk for building 9.0.23 against the newer O/S and compiler, etc, than it is to build 9.0.9 against the newer O/S and compiler, etc.  You assumed basically maximum risk when you choose to keep using version 9.0 and upgraded everything else around it to versions that were possibly never tested against it - and if they were tested it is more likely they were tested against 9.0.23 as it is years more current.
 
David J.