Re:Re: ran out of space in relation map - Mailing list pgsql-bugs

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