Обсуждение: ran out of space in relation map

Поиск
Список
Период
Сортировка

ran out of space in relation map

От
constzl
Дата:
Hi All:

Look at the following code.

"The map file should be kept to no more than one standard-size disk sector (ie 512 bytes)"
p, li { white-space: pre-wrap; }

p, li { white-space: pre-wrap; }

This means that the number of mapping objects can not be more than MAX_MAPPINGS, which is 62 now.

p, li { white-space: pre-wrap; }

If one day in the future, it does need to be more than 62, then what to do?


p, li { white-space: pre-wrap; }

In fact, I had such a problem. After I add some shared catalog relation (and its toast relation,index), the error

"ran out of space in relation map" occurs when initdb.

p, li { white-space: pre-wrap; }

After debugging, it is found that the number of shared objects is indeed more than 62, and of course, its size is

more than 512 bytes.

p, li { white-space: pre-wrap; }

Can someone help me? Thanks!

Best Regards

const.zl



Вложения

Re: ran out of space in relation map

От
Tom Lane
Дата:
constzl <const_sunny@126.com> writes:
> This means that the number of mapping objects can not be more than MAX_MAPPINGS, which is 62 now.

Yeah ...

> If one day in the future, it does need to be more than 62, then what to do?

Rethink your design?  The current system is not close to running
out of those slots, and I can't see any good reason for a large
increase in the number of shared catalogs.

If our backs were against the wall, we could rearrange things
on the assumption that the OIDs of mapped catalogs must fit in
16 bits, which would make room for 80 or so slots without
having to worry about torn writes.  We could also be a bit
charier about how many of these catalogs actually need toast
tables ...

            regards, tom lane



Re:Re: ran out of space in relation map

От
constzl
Дата:
Thanks for your reply!<br/><br/>In fact, The Greenplum v6.0 database has used 60 slots when initdb, and when I
developeda syntax feature based on GP6, <br/>for that I need to add a shared catalog and two indices, then the shared
relationmap run out.<br/><br/>see them as below<br/><br/>{mapoid = 1262, mapfilenode = 1262},
pg_database<br/>{mapoid= 2964, mapfilenode = 2964},    pg_db_role_setting<br/>{mapoid = 1213,    mapfilenode = 1213},
pg_tablespace<br/>{mapoid = 1136, mapfilenode = 1136},    pg_pltemplate<br/>{mapoid = 1260, mapfilenode = 1260},
pg_authid<br/>{mapoid= 1261, mapfilenode = 1261},    pg_auth_members<br/>{mapoid = 1214, mapfilenode = 1214},
pg_shdepend<br/>{mapoid= 2396, mapfilenode = 2396},    pg_shdescription<br/>{mapoid = 3592, mapfilenode = 3592},
pg_shseclabel<br/>{mapoid= 6026, mapfilenode = 6026},    pg_resqueue<br/>{mapoid = 6060,    mapfilenode = 6060},
pg_resqueuecapability<br/>{mapoid= 6059, mapfilenode = 6059},    pg_resourcetype<br/>{mapoid = 6436, mapfilenode =
6436},   pg_resgroup<br/>{mapoid = 6439, mapfilenode = 6439},    pg_resgroupcapability<br/>{mapoid = 5006, mapfilenode
=5006},    gp_configuration_history<br/>{mapoid = 5001,    mapfilenode = 5001},    gp_id<br/>{mapoid = 5003,
mapfilenode= 5003},    gp_version_at_initdb<br/>{mapoid = 5036, mapfilenode = 5036},
gp_segment_configuration<br/>{mapoid= 6070, mapfilenode = 6070},    pg_auth_time_constraint<br/>{mapoid = 6056,
mapfilenode= 6056},    pg_stat_last_shoperation<br/>{mapoid = 2846,    mapfilenode = 2846},    pg_shdescription
toast<br/>{mapoid= 2847, mapfilenode = 2847},    pg_shdescription    toast<br/>{mapoid = 2966, mapfilenode = 2966},
pg_db_role_setting   toast<br/>{mapoid = 2967, mapfilenode = 2967},    pg_db_role_setting    toast<br/>{mapoid = 6092,
mapfilenode= 6092},    gp_segment_configuration    toast<br/>{mapoid = 6093,    mapfilenode = 6093},
gp_segment_configuration   toast`<br/>{mapoid = 2676, mapfilenode = 2676},    pg_authid_rolname_index<br/>{mapoid =
2677,mapfilenode = 2677},    pg_authid_oid_index<br/>{mapoid = 6029, mapfilenode = 6029},
pg_authid_rolresqueue_index<br/>{mapoid= 6440, mapfilenode = 6440},    pg_authid_rolresgroup_index<br/>{mapoid = 2694,
 mapfilenode = 2694},    pg_auth_members_role_member_index<br/>{mapoid = 2695, mapfilenode = 2695},
pg_auth_members_member_role_index<br/>{mapoid= 6449, mapfilenode = 6449},
pg_auth_time_constraint_authid_index<br/>{mapoid= 2671, mapfilenode = 2671},    pg_database_datname_index<br/>{mapoid =
2672,mapfilenode = 2672},    pg_database_oid_index<br/>{mapoid = 2397,    mapfilenode = 2397},
pg_shdescription_o_c_index<br/>{mapoid= 1137, mapfilenode = 1137},    pg_pltemplate_name_index<br/>{mapoid = 1232,
mapfilenode= 1232},    pg_shdepend_depender_index<br/>{mapoid = 1233, mapfilenode = 1233},
pg_shdepend_reference_index<br/>{mapoid= 2697, mapfilenode = 2697},    pg_tablespace_oid_index<br/>{mapoid = 2698,
mapfilenode= 2698},    pg_tablespace_spcname_index<br/>{mapoid = 2965, mapfilenode = 2965},
pg_db_role_setting_databaseid_rol_index<br/>{mapoid= 3593, mapfilenode = 3593},
pg_shseclabel_object_index<br/>{mapoid= 6057, mapfilenode = 6057},    pg_statlastshop_classid_objid_index<br/>{mapoid =
6058,mapfilenode = 6058},    pg_statlastshop_classid_objid_staactionname_index<br/>{mapoid = 6027,    mapfilenode =
6027},   pg_resqueue_oid_index<br/>{mapoid = 6028, mapfilenode = 6028},    pg_resqueue_rsqname_index<br/>{mapoid =
6061,mapfilenode = 6061},    pg_resourcetype_oid_index<br/>{mapoid = 6062, mapfilenode = 6062},
pg_resourcetype_restypid_index<br/>{mapoid= 6063, mapfilenode = 6063},    pg_resourcetype_resname_index<br/>{mapoid =
6441,   mapfilenode = 6441},    pg_resqueuecapability_oid_index<br/>{mapoid = 6442, mapfilenode = 6442},
pg_resqueuecapability_resqueueid_index<br/>{mapoid= 6443, mapfilenode = 6443},
pg_resqueuecapability_restypid_index<br/>{mapoid= 6447, mapfilenode = 6447},    pg_resgroup_oid_index<br/>{mapoid =
6444,mapfilenode = 6444},    pg_resgroup_rsgname_index<br/>{mapoid = 6448,    mapfilenode = 6448},
pg_resgroupcapability_oid_index<br/>{mapoid= 6445, mapfilenode = 6445},
pg_resgroupcapability_resgroupid_reslimittype_index<br/>{mapoid= 6446, mapfilenode = 6446},
pg_resgroupcapability_resgroupid_index<br/>{mapoid= 6106, mapfilenode = 6106},
gp_segment_config_content_preferred_role_index<br/>{mapoid= 6107, mapfilenode = 6107},    gp_segment_config_dbid_index 
At 2019-08-24 13:58:22, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>constzl <const_sunny@126.com> writes:
>> This means that the number of mapping objects can not be more than MAX_MAPPINGS, which is 62 now.
>
>Yeah ...
>
>> If one day in the future, it does need to be more than 62, then what to do?
>
>Rethink your design?  The current system is not close to running
>out of those slots, and I can't see any good reason for a large
>increase in the number of shared catalogs.
>
>If our backs were against the wall, we could rearrange things
>on the assumption that the OIDs of mapped catalogs must fit in
>16 bits, which would make room for 80 or so slots without
>having to worry about torn writes.  We could also be a bit
>charier about how many of these catalogs actually need toast
>tables ...
>
>            regards, tom lane