Re:Re: ran out of space in relation map

From: constzl <const_sunny(at)126(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re:Re: ran out of space in relation map
Date: 2019-08-24 06:32:28
Message-ID: 4d900af2.182e.16cc25380d7.Coremail.const_sunny@126.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thanks for your reply!<br/><br/>In fact, The Greenplum v6.0 database has used 60 slots when initdb, and when I developed a syntax feature based on GP6, <br/>for that I need to add a shared catalog and two indices, then the shared relation map 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>constzl <const_sunny(at)126(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Marko Tiikkaja 2019-08-24 07:08:42 Re: data modifying WITH seems to drop rows in cascading updates -- bug?
Previous Message Tom Lane 2019-08-24 05:58:22 Re: ran out of space in relation map