Re: PostgreSQL 9.2.4 + CentOS 6.5 64 bit - segfault error in initdb

Hello,

I have installed the following RPM on CentOS 6.5 64 bit -
uuid-1.5.1-4.rhel5.x86_64
postgresql92-contrib-9.2.4-1PGDG.rhel5.x86_64
postgresql92-9.2.4-1PGDG.rhel5.x86_64
postgresql92-server-9.2.4-1PGDG.rhel5.x86_64
postgresql92-libs-9.2.4-1PGDG.rhel5.x86_64

Kernel version is -
kernel-2.6.32-431.17.1.el6.x86_64
kernel-firmware-2.6.32-431.17.1.el6.noarch

The CentOS server is a VM running on top of VMware with 4CPUs [2.4GHz each]
& 9GB of RAM. No other application runs on this server.

The RPM get installed successfully, but when I issue the "service
postgresql-9.2 initdb" command, it gets stuck for 5-10 minutes & then says
failed. The pgstartup.log file has only 1 line -
Segmentation fault (core dumped)

Any idea what is going wrong? How to fix it? I'm open to try multiple
installation attempts [as it is a VM & I can re-install as needed]

Thanks
Bhushan Pathak

Hi,
On Wed, 2014-06-04 at 17:50 +0530, Bhushan Pathak wrote:

> The RPM get installed successfully, but when I issue the "service
> postgresql-9.2 initdb" command, it gets stuck for 5-10 minutes & then
> says failed. The pgstartup.log file has only 1 line -
> Segmentation fault (core dumped)

Can you please edit /etc/init.d/postgresql-9.2, go to line 235 which is
like this:

http://svn.pgrpms.org/browser/rpm/redhat/9.2/postgresql/EL-6/postgresql.init#L235

and then add -d parameter after initdb, and run it again? This will
throw debug messages to log file, which may give input to the people who
can find out the issue.

Regards,

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 06/04/2014 05:20 AM, Bhushan Pathak wrote:
> Hello,
>
> I have installed the following RPM on CentOS 6.5 64 bit -
> uuid-1.5.1-4.rhel5.x86_64
> postgresql92-contrib-9.2.4-1PGDG.rhel5.x86_64
> postgresql92-9.2.4-1PGDG.rhel5.x86_64
> postgresql92-server-9.2.4-1PGDG.rhel5.x86_64
> postgresql92-libs-9.2.4-1PGDG.rhel5.x86_64
>
> Kernel version is -
> kernel-2.6.32-431.17.1.el6.x86_64
> kernel-firmware-2.6.32-431.17.1.el6.noarch
>
> The CentOS server is a VM running on top of VMware with 4CPUs [2.4GHz
> each] & 9GB of RAM. No other application runs on this server.
>
> The RPM get installed successfully, but when I issue the "service
> postgresql-9.2 initdb" command, it gets stuck for 5-10 minutes & then
> says failed. The pgstartup.log file has only 1 line -
> Segmentation fault (core dumped)

Is the data directory created?

>
> Any idea what is going wrong? How to fix it? I'm open to try multiple
> installation attempts [as it is a VM & I can re-install as needed]

What happens if you use pg_ctl to initdb the cluster?

>
> Thanks
> Bhushan Pathak

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

It did create the data directory as well pg_log directory. I ran the initdb
again with -d option, but it still printed the same line in the startup
log, nothing more.
$SU -l postgres -c "$PGENGINE/initdb --pgdata='$PGDATA' --auth='ident'
$LOCALESTRING -d" >> "$PGLOG" 2>&1 < /dev/null

I then ran the pg_ctl command as follows
su - postgres
cd /usr/pgsql-9.2/bin
./pg_ctl initdb -D /var/lib/pgsql/data -o '--auth="ident"
--locale=en_US.UTF-8 -d'

This command did print a lot of debug messages on CLI -
EBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: building index "pg_range_rngtypid_index" on table "pg_range"
DEBUG: building index "pg_extension_name_index" on table "pg_extension"
DEBUG: building index "pg_extension_oid_index" on table "pg_extension"
DEBUG: building index "pg_shseclabel_object_index" on table "pg_shseclabel"
DEBUG: building index "pg_seclabel_object_index" on table "pg_seclabel"
DEBUG: building index "pg_db_role_setting_databaseid_rol_index" on table
"pg_db_role_setting"
DEBUG: building index "pg_default_acl_oid_index" on table "pg_default_acl"
DEBUG: building index "pg_default_acl_role_nsp_obj_index" on table
"pg_default_acl"
DEBUG: building index "pg_foreign_table_relid_index" on table
"pg_foreign_table"
DEBUG: building index "pg_user_mapping_user_server_index" on table
"pg_user_mapping"
DEBUG: building index "pg_user_mapping_oid_index" on table
"pg_user_mapping"
DEBUG: building index "pg_foreign_server_name_index" on table
"pg_foreign_server"
DEBUG: building index "pg_foreign_server_oid_index" on table
"pg_foreign_server"
DEBUG: building index "pg_foreign_data_wrapper_name_index" on table
"pg_foreign_data_wrapper"
DEBUG: building index "pg_foreign_data_wrapper_oid_index" on table
"pg_foreign_data_wrapper"
DEBUG: building index "pg_type_typname_nsp_index" on table "pg_type"
DEBUG: building index "pg_type_oid_index" on table "pg_type"
DEBUG: building index "pg_ts_template_oid_index" on table "pg_ts_template"
DEBUG: building index "pg_ts_template_tmplname_index" on table
"pg_ts_template"
DEBUG: building index "pg_ts_parser_oid_index" on table "pg_ts_parser"
DEBUG: building index "pg_ts_parser_prsname_index" on table "pg_ts_parser"
DEBUG: building index "pg_ts_dict_oid_index" on table "pg_ts_dict"
DEBUG: building index "pg_ts_dict_dictname_index" on table "pg_ts_dict"
DEBUG: building index "pg_ts_config_map_index" on table "pg_ts_config_map"
DEBUG: building index "pg_ts_config_oid_index" on table "pg_ts_config"
DEBUG: building index "pg_ts_config_cfgname_index" on table "pg_ts_config"
DEBUG: building index "pg_trigger_oid_index" on table "pg_trigger"
DEBUG: building index "pg_trigger_tgrelid_tgname_index" on table
"pg_trigger"
DEBUG: building index "pg_trigger_tgconstraint_index" on table "pg_trigger"
DEBUG: building index "pg_tablespace_spcname_index" on table
"pg_tablespace"
DEBUG: building index "pg_tablespace_oid_index" on table "pg_tablespace"
DEBUG: building index "pg_statistic_relid_att_inh_index" on table
"pg_statistic"
DEBUG: building index "pg_shdepend_reference_index" on table "pg_shdepend"
DEBUG: building index "pg_shdepend_depender_index" on table "pg_shdepend"
DEBUG: building index "pg_rewrite_rel_rulename_index" on table "pg_rewrite"
DEBUG: building index "pg_rewrite_oid_index" on table "pg_rewrite"
DEBUG: building index "pg_proc_proname_args_nsp_index" on table "pg_proc"
DEBUG: building index "pg_proc_oid_index" on table "pg_proc"
DEBUG: building index "pg_pltemplate_name_index" on table "pg_pltemplate"
DEBUG: building index "pg_opfamily_oid_index" on table "pg_opfamily"
DEBUG: building index "pg_opfamily_am_name_nsp_index" on table
"pg_opfamily"
DEBUG: building index "pg_operator_oprname_l_r_n_index" on table
"pg_operator"
DEBUG: building index "pg_operator_oid_index" on table "pg_operator"
DEBUG: building index "pg_opclass_oid_index" on table "pg_opclass"
DEBUG: building index "pg_opclass_am_name_nsp_index" on table "pg_opclass"
DEBUG: building index "pg_namespace_oid_index" on table "pg_namespace"
DEBUG: building index "pg_namespace_nspname_index" on table "pg_namespace"
DEBUG: building index "pg_largeobject_metadata_oid_index" on table
"pg_largeobject_metadata"
DEBUG: building index "pg_largeobject_loid_pn_index" on table
"pg_largeobject"
DEBUG: building index "pg_language_oid_index" on table "pg_language"
DEBUG: building index "pg_language_name_index" on table "pg_language"
DEBUG: building index "pg_inherits_parent_index" on table "pg_inherits"
DEBUG: building index "pg_inherits_relid_seqno_index" on table
"pg_inherits"
DEBUG: building index "pg_index_indexrelid_index" on table "pg_index"
DEBUG: building index "pg_index_indrelid_index" on table "pg_index"
DEBUG: building index "pg_enum_typid_sortorder_index" on table "pg_enum"
DEBUG: building index "pg_enum_typid_label_index" on table "pg_enum"
DEBUG: building index "pg_enum_oid_index" on table "pg_enum"
DEBUG: building index "pg_shdescription_o_c_index" on table
"pg_shdescription"
DEBUG: building index "pg_description_o_c_o_index" on table
"pg_description"
DEBUG: building index "pg_depend_reference_index" on table "pg_depend"
DEBUG: building index "pg_depend_depender_index" on table "pg_depend"
DEBUG: building index "pg_database_oid_index" on table "pg_database"
DEBUG: building index "pg_database_datname_index" on table "pg_database"
DEBUG: building index "pg_conversion_oid_index" on table "pg_conversion"
DEBUG: building index "pg_conversion_name_nsp_index" on table
"pg_conversion"
DEBUG: building index "pg_conversion_default_index" on table
"pg_conversion"
DEBUG: building index "pg_constraint_oid_index" on table "pg_constraint"
DEBUG: building index "pg_constraint_contypid_index" on table
"pg_constraint"
DEBUG: building index "pg_constraint_conrelid_index" on table
"pg_constraint"
DEBUG: building index "pg_constraint_conname_nsp_index" on table
"pg_constraint"
DEBUG: building index "pg_collation_oid_index" on table "pg_collation"
DEBUG: building index "pg_collation_name_enc_nsp_index" on table
"pg_collation"
DEBUG: building index "pg_class_relname_nsp_index" on table "pg_class"
DEBUG: building index "pg_class_oid_index" on table "pg_class"
DEBUG: building index "pg_cast_source_target_index" on table "pg_cast"
DEBUG: building index "pg_cast_oid_index" on table "pg_cast"
DEBUG: building index "pg_auth_members_member_role_index" on table
"pg_auth_members"
DEBUG: building index "pg_auth_members_role_member_index" on table
"pg_auth_members"
DEBUG: building index "pg_authid_oid_index" on table "pg_authid"
DEBUG: building index "pg_authid_rolname_index" on table "pg_authid"
DEBUG: building index "pg_attribute_relid_attnum_index" on table
"pg_attribute"
DEBUG: building index "pg_attribute_relid_attnam_index" on table
"pg_attribute"
DEBUG: building index "pg_attrdef_oid_index" on table "pg_attrdef"
DEBUG: building index "pg_attrdef_adrelid_adnum_index" on table
"pg_attrdef"
DEBUG: building index "pg_amproc_oid_index" on table "pg_amproc"
DEBUG: building index "pg_amproc_fam_proc_index" on table "pg_amproc"
DEBUG: building index "pg_amop_oid_index" on table "pg_amop"
DEBUG: building index "pg_amop_opr_fam_index" on table "pg_amop"
DEBUG: building index "pg_amop_fam_strat_index" on table "pg_amop"
DEBUG: building index "pg_am_oid_index" on table "pg_am"
DEBUG: building index "pg_am_name_index" on table "pg_am"
DEBUG: building index "pg_aggregate_fnoid_index" on table "pg_aggregate"
DEBUG: building index "pg_toast_2964_index" on table "pg_toast_2964"
DEBUG: building index "pg_toast_2396_index" on table "pg_toast_2396"
DEBUG: building index "pg_toast_2620_index" on table "pg_toast_2620"
DEBUG: building index "pg_toast_2619_index" on table "pg_toast_2619"
DEBUG: building index "pg_toast_3596_index" on table "pg_toast_3596"
DEBUG: building index "pg_toast_2618_index" on table "pg_toast_2618"
DEBUG: building index "pg_toast_1255_index" on table "pg_toast_1255"
DEBUG: building index "pg_toast_2609_index" on table "pg_toast_2609"
DEBUG: building index "pg_toast_2606_index" on table "pg_toast_2606"
DEBUG: building index "pg_toast_2604_index" on table "pg_toast_2604"
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 0/1/43, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: shmem_exit(0): 10 callbacks to make
LOG: shutting down
DEBUG: SlruScanDirectory invoking callback on pg_multixact/offsets/0000
DEBUG: SlruScanDirectory invoking callback on pg_multixact/members/0000
DEBUG: attempting to remove WAL segments older than log file
000000010000000000000000
DEBUG: SlruScanDirectory invoking callback on pg_subtrans/0000
LOG: database system is shut down
DEBUG: proc_exit(0): 3 callbacks to make
DEBUG: exit(0)
DEBUG: shmem_exit(-1): 0 callbacks to make
DEBUG: proc_exit(-1): 0 callbacks to make
ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating collations ... initdb: locale name has non-ASCII characters,
skipped: "bokmål"
initdb: locale name has non-ASCII characters, skipped: "français"
could not determine encoding for locale "hy_AM.armscii8": codeset is
"ARMSCII-8"
could not determine encoding for locale "ka_GE": codeset is "GEORGIAN-PS"
could not determine encoding for locale "ka_GE.georgianps": codeset is
"GEORGIAN-PS"
could not determine encoding for locale "kk_KZ": codeset is "PT154"
could not determine encoding for locale "kk_KZ.pt154": codeset is "PT154"
could not determine encoding for locale "tg_TJ": codeset is "KOI8-T"
could not determine encoding for locale "tg_TJ.koi8t": codeset is "KOI8-T"
could not determine encoding for locale "thai": codeset is "TIS-620"
could not determine encoding for locale "th_TH": codeset is "TIS-620"
could not determine encoding for locale "th_TH.tis620": codeset is "TIS-620"
could not determine encoding for locale "vi_VN.tcvn": codeset is
"TCVN5712-1"
ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
loading PL/pgSQL server-side language ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

Success. You can now start the database server using:

/usr/pgsql-9.2/bin/postgres -D /var/lib/pgsql/data
or
/usr/pgsql-9.2/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start

And also seemed to be successful. But when I quit the postgres shell, tried
to restart the service as root user, it has failed with the following
message on CLI -
Stopping postgresql service: [ OK ]
Starting postgresql service: [FAILED]

pgstartup log has the same line -
Segmentation fault (core dumped)

Where is this core dump file generated? How do we proceed further from here?

Thanks
Bhushan Pathak

On Wed, Jun 4, 2014 at 7:04 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 06/04/2014 05:20 AM, Bhushan Pathak wrote:
>
>> Hello,
>>
>> I have installed the following RPM on CentOS 6.5 64 bit -
>> uuid-1.5.1-4.rhel5.x86_64
>> postgresql92-contrib-9.2.4-1PGDG.rhel5.x86_64
>> postgresql92-9.2.4-1PGDG.rhel5.x86_64
>> postgresql92-server-9.2.4-1PGDG.rhel5.x86_64
>> postgresql92-libs-9.2.4-1PGDG.rhel5.x86_64
>>
>> Kernel version is -
>> kernel-2.6.32-431.17.1.el6.x86_64
>> kernel-firmware-2.6.32-431.17.1.el6.noarch
>>
>> The CentOS server is a VM running on top of VMware with 4CPUs [2.4GHz
>> each] & 9GB of RAM. No other application runs on this server.
>>
>> The RPM get installed successfully, but when I issue the "service
>> postgresql-9.2 initdb" command, it gets stuck for 5-10 minutes & then
>> says failed. The pgstartup.log file has only 1 line -
>> Segmentation fault (core dumped)
>>
>
> Is the data directory created?
>
>
>
>> Any idea what is going wrong? How to fix it? I'm open to try multiple
>> installation attempts [as it is a VM & I can re-install as needed]
>>
>
> What happens if you use pg_ctl to initdb the cluster?
>
>
>> Thanks
>> Bhushan Pathak
>>
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

On 06/05/2014 09:11 AM, Bhushan Pathak wrote:
> It did create the data directory as well pg_log directory. I ran the
> initdb again with -d option, but it still printed the same line in the
> startup log, nothing more.
> $SU -l postgres -c "$PGENGINE/initdb --pgdata='$PGDATA' --auth='ident'
> $LOCALESTRING -d" >> "$PGLOG" 2>&1 < /dev/null
>
> I then ran the pg_ctl command as follows
> su - postgres
> cd /usr/pgsql-9.2/bin
> ./pg_ctl initdb -D /var/lib/pgsql/data -o '--auth="ident"
> --locale=en_US.UTF-8 -d'
>

Try this with initdb directly. I personally am confused with what pg_ctl
does with -o since -d is an option to postgres not initdb and --locale
is an option to initdb not postgres.

> creating collations ... initdb: locale name has non-ASCII characters,
> skipped: "bokmål"
> initdb: locale name has non-ASCII characters, skipped: "français"
> could not determine encoding for locale "hy_AM.armscii8": codeset is
> "ARMSCII-8"
> could not determine encoding for locale "ka_GE": codeset is "GEORGIAN-PS"
> could not determine encoding for locale "ka_GE.georgianps": codeset is
> "GEORGIAN-PS"
> could not determine encoding for locale "kk_KZ": codeset is "PT154"
> could not determine encoding for locale "kk_KZ.pt154": codeset is "PT154"
> could not determine encoding for locale "tg_TJ": codeset is "KOI8-T"
> could not determine encoding for locale "tg_TJ.koi8t": codeset is "KOI8-T"
> could not determine encoding for locale "thai": codeset is "TIS-620"
> could not determine encoding for locale "th_TH": codeset is "TIS-620"
> could not determine encoding for locale "th_TH.tis620": codeset is "TIS-620"
> could not determine encoding for locale "vi_VN.tcvn": codeset is
> "TCVN5712-1"

Looks like Postgres is having a problem determining what the locale is
for your setup.

What is your locale?

> Success. You can now start the database server using:
>
> /usr/pgsql-9.2/bin/postgres -D /var/lib/pgsql/data
> or
> /usr/pgsql-9.2/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start
>
>
> And also seemed to be successful. But when I quit the postgres shell,
> tried to restart the service as root user, it has failed with the
> following message on CLI -

So you are using the system start script?

What happens if you do pg_ctl start -D /var/lib/pgsql/data as the
postgres user?

> Stopping postgresql service: [ OK ]
> Starting postgresql service: [FAILED]
>
> pgstartup log has the same line -
> Segmentation fault (core dumped)
>
> Where is this core dump file generated? How do we proceed further from here?

Take a look at this Wiki page:

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

>
> Thanks
> Bhushan Pathak
>
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

My locale is set to en_US.UTF-8, that's what the service script is using.

If I try to start the server with pg_ctl command, it does start -
./pg_ctl start -D /var/lib/pgsql/data -l /tmp/logfile
server starting

What would this mean? The service script does not work but manually issuing
pg_ctl commands work.

Thanks
Bhushan Pathak

On Fri, Jun 6, 2014 at 5:48 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 06/05/2014 09:11 AM, Bhushan Pathak wrote:
>
>> It did create the data directory as well pg_log directory. I ran the
>> initdb again with -d option, but it still printed the same line in the
>> startup log, nothing more.
>> $SU -l postgres -c "$PGENGINE/initdb --pgdata='$PGDATA' --auth='ident'
>> $LOCALESTRING -d" >> "$PGLOG" 2>&1 < /dev/null
>>
>> I then ran the pg_ctl command as follows
>> su - postgres
>> cd /usr/pgsql-9.2/bin
>> ./pg_ctl initdb -D /var/lib/pgsql/data -o '--auth="ident"
>> --locale=en_US.UTF-8 -d'
>>
>>
> Try this with initdb directly. I personally am confused with what pg_ctl
> does with -o since -d is an option to postgres not initdb and --locale is
> an option to initdb not postgres.
>
>
>
> creating collations ... initdb: locale name has non-ASCII characters,
>> skipped: "bokmål"
>> initdb: locale name has non-ASCII characters, skipped: "français"
>> could not determine encoding for locale "hy_AM.armscii8": codeset is
>> "ARMSCII-8"
>> could not determine encoding for locale "ka_GE": codeset is "GEORGIAN-PS"
>> could not determine encoding for locale "ka_GE.georgianps": codeset is
>> "GEORGIAN-PS"
>> could not determine encoding for locale "kk_KZ": codeset is "PT154"
>> could not determine encoding for locale "kk_KZ.pt154": codeset is "PT154"
>> could not determine encoding for locale "tg_TJ": codeset is "KOI8-T"
>> could not determine encoding for locale "tg_TJ.koi8t": codeset is "KOI8-T"
>> could not determine encoding for locale "thai": codeset is "TIS-620"
>> could not determine encoding for locale "th_TH": codeset is "TIS-620"
>> could not determine encoding for locale "th_TH.tis620": codeset is
>> "TIS-620"
>> could not determine encoding for locale "vi_VN.tcvn": codeset is
>> "TCVN5712-1"
>>
>
> Looks like Postgres is having a problem determining what the locale is for
> your setup.
>
> What is your locale?
>
>
>
> Success. You can now start the database server using:
>>
>> /usr/pgsql-9.2/bin/postgres -D /var/lib/pgsql/data
>> or
>> /usr/pgsql-9.2/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start
>>
>>
>> And also seemed to be successful. But when I quit the postgres shell,
>> tried to restart the service as root user, it has failed with the
>> following message on CLI -
>>
>
> So you are using the system start script?
>
> What happens if you do pg_ctl start -D /var/lib/pgsql/data as the postgres
> user?
>
>
>
> Stopping postgresql service: [ OK ]
>> Starting postgresql service: [FAILED]
>>
>> pgstartup log has the same line -
>> Segmentation fault (core dumped)
>>
>> Where is this core dump file generated? How do we proceed further from
>> here?
>>
>
> Take a look at this Wiki page:
>
> https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_
> a_running_PostgreSQL_backend_on_Linux/BSD
>
>
>
>> Thanks
>> Bhushan Pathak
>>
>>
>>
>>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

On 06/06/2014 12:29 AM, Bhushan Pathak wrote:
> My locale is set to en_US.UTF-8, that's what the service script is using.
>
> If I try to start the server with pg_ctl command, it does start -
> ./pg_ctl start -D /var/lib/pgsql/data -l /tmp/logfile
> server starting
>
> What would this mean? The service script does not work but manually
> issuing pg_ctl commands work.

The service script is not correct?

Could you post the contents of the script?

Do you have another instance of Postgres installed by any chance?

Have you had another instance/version installed in the past, something
that might have left parts of itself around?

>
> Thanks
> Bhushan Pathak
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

On 06/06/2014 12:29 AM, Bhushan Pathak wrote:
> My locale is set to en_US.UTF-8, that's what the service script is using.
>
> If I try to start the server with pg_ctl command, it does start -
> ./pg_ctl start -D /var/lib/pgsql/data -l /tmp/logfile
> server starting
>
> What would this mean? The service script does not work but manually
> issuing pg_ctl commands work.

Meant to add to my previous post:

Does anything show up in the system log when the service script fails,
beside the segfault?

>
> Thanks
> Bhushan Pathak

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

Bhushan Pathak <bhushan(dot)pathak02(at)gmail(dot)com> writes:
>>> Stopping postgresql service: [ OK ]
>>> Starting postgresql service: [FAILED]
>>>
>>> pgstartup log has the same line -
>>> Segmentation fault (core dumped)
>>>
>>> Where is this core dump file generated? How do we proceed further from
>>> here?

FWIW, I'd expect any such core to be generated either in postgres'
home directory or the $PGDATA directory, depending on what is
failing when. If you don't see a core, it's likely because the failing
program is running under "ulimit -c 0", which is the default environment
for daemons (for security reasons). Try adding "ulimit -c unlimited"
to the start script and/or the postgres user's ~/.bash_profile to see
if you can get a core file for debugging.

The issue seems like it must trace back to some difference in the
normal shell environment of the postgres user versus the environment
set up by "service" ... but it's not clear yet what that difference
is.

Also, it's not very clear whether you're trying to use the Red Hat/CentOS
packaging of PG, or the PGDG packaging. As Adrian alluded to, those are
not terribly compatible --- if you've got fragments of both laying about,
that could be causing issues.

regards, tom lane

I do not have any earlier versions of postgres installed, neither a
parallel instance running. In the pgstartup.log file, only the segfault
error is recorded, nothing else.

I have downloaded the following RPMs from
http://yum.postgresql.org/9.2/redhat/rhel-5.6-x86_64/

postgresql92-9.2.4-1PGDG.rhel5.x86_64.rpm
postgresql92-libs-9.2.4-1PGDG.rhel5.x86_64.rpm
postgresql92-contrib-9.2.4-1PGDG.rhel5.x86_64.rpm
postgresql92-server-9.2.4-1PGDG.rhel5.x86_64.rpm

A core file was not generated. I will try with adding the ulimit command to
the service script. Attached is the service script.

Thanks
Bhushan Pathak

On Fri, Jun 6, 2014 at 8:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Bhushan Pathak <bhushan(dot)pathak02(at)gmail(dot)com> writes:
> >>> Stopping postgresql service: [ OK ]
> >>> Starting postgresql service: [FAILED]
> >>>
> >>> pgstartup log has the same line -
> >>> Segmentation fault (core dumped)
> >>>
> >>> Where is this core dump file generated? How do we proceed further from
> >>> here?
>
> FWIW, I'd expect any such core to be generated either in postgres'
> home directory or the $PGDATA directory, depending on what is
> failing when. If you don't see a core, it's likely because the failing
> program is running under "ulimit -c 0", which is the default environment
> for daemons (for security reasons). Try adding "ulimit -c unlimited"
> to the start script and/or the postgres user's ~/.bash_profile to see
> if you can get a core file for debugging.
>
> The issue seems like it must trace back to some difference in the
> normal shell environment of the postgres user versus the environment
> set up by "service" ... but it's not clear yet what that difference
> is.
>
> Also, it's not very clear whether you're trying to use the Red Hat/CentOS
> packaging of PG, or the PGDG packaging. As Adrian alluded to, those are
> not terribly compatible --- if you've got fragments of both laying about,
> that could be causing issues.
>
> regards, tom lane
>

Hi,

On Mon, 2014-06-09 at 14:23 +0530, Bhushan Pathak wrote:
> A core file was not generated.

Can you please also install the -debuginfo package?

Regards,

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

Trying to figure out shell environment differences between the service
script & postgres shell, if I comment out the following variable in profile
file/add them after performing initdb operation, the postgresql operations
seem to work fine -
PATH=$PATH:/usr/pgsql-9.2/bin
export PATH
export POSTGRESQL_JDBC_DRIVER=/opt/lib/postgresql-9.2-1003.jdbc4.jar
export PG_HOME=/var/lib/pgsql/data/

These variables are needed by a few cron scripts that would be installed
later on after my postgres config completes successfully.

The yum postgresql link I used earlier to download the RPM dos not the
debuginfo package for 9.2.4 version. Will it be OK to use the latest
debuginfo package with the rest being on version 9.2.4? Or I will have to
use all the latest RPM packages?

Thanks
Bhushan Pathak

On Mon, Jun 9, 2014 at 3:34 PM, Devrim Gündüz <devrim(at)gunduz(dot)org> wrote:

>
> Hi,
>
> On Mon, 2014-06-09 at 14:23 +0530, Bhushan Pathak wrote:
> > A core file was not generated.
>
> Can you please also install the -debuginfo package?
>
> Regards,
>
> --
> Devrim GÜNDÜZ
> Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
> PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
> Twitter: @DevrimGunduz , @DevrimGunduzTR
>
>

On 06/09/2014 04:02 AM, Bhushan Pathak wrote:
> Trying to figure out shell environment differences between the service
> script & postgres shell, if I comment out the following variable in
> profile file/add them after performing initdb operation, the postgresql
> operations seem to work fine -

In the init script the only thing that is exported that could possibly
conflict is PGDATA which is the same as your PG_HOME, but they are
assigned to different variables so I am not sure where the conflict
would occur.

> PATH=$PATH:/usr/pgsql-9.2/bin
> export PATH
This seems alright, though not needed by the script as it uses the full
path when calling the binaries.

> export POSTGRESQL_JDBC_DRIVER=/opt/lib/postgresql-9.2-1003.jdbc4.jar
Not sure how the above would have any effect with the initdb as Java is
not involved.

> export PG_HOME=/var/lib/pgsql/data/
This is redundant, I would just use the PGDATA environment variable
exported by the script.

>
> These variables are needed by a few cron scripts that would be installed
> later on after my postgres config completes successfully.
>
> The yum postgresql link I used earlier to download the RPM dos not the
> debuginfo package for 9.2.4 version. Will it be OK to use the latest
> debuginfo package with the rest being on version 9.2.4? Or I will have
> to use all the latest RPM packages?
>
> Thanks
> Bhushan Pathak
>
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

On 06/09/2014 01:53 AM, Bhushan Pathak wrote:
>
> I do not have any earlier versions of postgres installed, neither a
> parallel instance running. In the pgstartup.log file, only the segfault
> error is recorded, nothing else.
>
> I have downloaded the following RPMs from
> http://yum.postgresql.org/9.2/redhat/rhel-5.6-x86_64/

I thought you where on Centos 6.5 would you not need?:

http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/repoview/

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

I will try the the RPMs from the rhel 6 link & post updates.

Thanks
Bhushan Pathak

On Mon, Jun 9, 2014 at 8:06 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 06/09/2014 01:53 AM, Bhushan Pathak wrote:
>
>>
>> I do not have any earlier versions of postgres installed, neither a
>> parallel instance running. In the pgstartup.log file, only the segfault
>> error is recorded, nothing else.
>>
>> I have downloaded the following RPMs from
>> http://yum.postgresql.org/9.2/redhat/rhel-5.6-x86_64/
>>
>
> I thought you where on Centos 6.5 would you not need?:
>
> http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/repoview/
>
>
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

Have not faced any issues with the rhel6 RPMs. Thanks for your time & help.

Regards
Bhushan Pathak

On Tue, Jun 10, 2014 at 4:00 PM, Bhushan Pathak <bhushan(dot)pathak02(at)gmail(dot)com>
wrote:

> I will try the the RPMs from the rhel 6 link & post updates.
>
> Thanks
> Bhushan Pathak
>
>
> On Mon, Jun 9, 2014 at 8:06 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
> wrote:
>
>> On 06/09/2014 01:53 AM, Bhushan Pathak wrote:
>>
>>>
>>> I do not have any earlier versions of postgres installed, neither a
>>> parallel instance running. In the pgstartup.log file, only the segfault
>>> error is recorded, nothing else.
>>>
>>> I have downloaded the following RPMs from
>>> http://yum.postgresql.org/9.2/redhat/rhel-5.6-x86_64/
>>>
>>
>> I thought you where on Centos 6.5 would you not need?:
>>
>> http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/repoview/
>>
>>
>>
>>
>> --
>> Adrian Klaver
>> adrian(dot)klaver(at)aklaver(dot)com
>>
>
>