Postgres Pro
Downloads
Home   >   mailing lists

Thread: problem with self built postgres 9.0.9

problem with self built postgres 9.0.9

From
Gabriele Bulfon
Date:
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

Re: problem with self built postgres 9.0.9

From
Adrian Klaver
Date:
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
adrian.klaver@aklaver.com

Re: problem with self built postgres 9.0.9

From
Gabriele Bulfon
Date:
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 <adrian.klaver@aklaver.com>
A: Gabriele Bulfon <gbulfon@sonicle.com> pgsql-general@lists.postgresql.org
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
adrian.klaver@aklaver.com


Re: problem with self built postgres 9.0.9

From
"David G. Johnston"
Date:
On Fri, May 29, 2020 at 7:08 AM Gabriele Bulfon <gbulfon@sonicle.com> 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.

Re: problem with self built postgres 9.0.9

From
Tom Lane
Date:
Gabriele Bulfon <gbulfon@sonicle.com> 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

Re: problem with self built postgres 9.0.9

From
Gabriele Bulfon
Date:
I will consider the upgrade, thanks a lot!

Gabriele




Da: David G. Johnston <david.g.johnston@gmail.com>
A: Gabriele Bulfon <gbulfon@sonicle.com>
Cc: Adrian Klaver <adrian.klaver@aklaver.com>pgsql-generallists.postgresql.org <pgsql-general@lists.postgresql.org>
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 <gbulfon@sonicle.com> 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.