problem with self built postgres 9.0.9
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 Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon
Re: problem with self built postgres 9.0.9
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 Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon -- Da: Adrian Klaver A: Gabriele Bulfon 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 *Music: *http://www.gabrielebulfon.com *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon -- Adrian Klaver adrian.kla...@aklaver.com
Re: problem with self built postgres 9.0.9
I will consider the upgrade, thanks a lot! Gabriele Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: David G. Johnston A: Gabriele Bulfon Cc: Adrian Klaver pgsql-generallists.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 gbul...@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.
