What is the significance of '0x6000' in the OID of composite_type column type in PostgreSQL?

I'm analyzing packet in PostgreSQL.
in Result packet, table OID usually above '0x6000' (ex, 0x6026)
In the other hand, in column OID of known types(int, varchar, byte, etc..) are usually under 0x6000.

but typd OID of composite_type (user-defined column type) represents over 0x6000 (ex, 0x6024)
I guess '0x6000' will be boundary between user-defined column and system-defined(known)

What means of '0x6000'? is composite_type start value? or '0x6024' is OID of composite_type?

In PostgreSQL JDBC, varchar is 1043(0x413), int is 21(0x15), but there are no information of composite_type.

Low Object IDs (OIDs) have a special meaning in PostgreSQL, but the boundaries are different from what you think. 0x6000 has no special meaning in PostgreSQL.

This is best explained by quoting the relevant parts of src/include/access/transam.h:

/* ----------
 *      Object ID (OID) zero is InvalidOid.
 *
 *      OIDs 1-9999 are reserved for manual assignment (see .dat files in
 *      src/include/catalog/).  Of these, 8000-9999 are reserved for
 *      development purposes (such as in-progress patches and forks);
 *      they should not appear in released versions.
 *
 *      OIDs 10000-11999 are reserved for assignment by genbki.pl, for use
 *      when the .dat files in src/include/catalog/ do not specify an OID
 *      for a catalog entry that requires one.  Note that genbki.pl assigns
 *      these OIDs independently in each catalog, so they're not guaranteed
 *      to be globally unique.  Furthermore, the bootstrap backend and
 *      initdb's post-bootstrap processing can also assign OIDs in this range.
 *      The normal OID-generation logic takes care of any OID conflicts that
 *      might arise from that.
 *
 *      OIDs 12000-16383 are reserved for unpinned objects created by initdb's
 *      post-bootstrap processing.  initdb forces the OID generator up to
 *      12000 as soon as it's made the pinned objects it's responsible for.
 *
 *      OIDs beginning at 16384 are assigned from the OID generator
 *      during normal multiuser operation.  (We force the generator up to
 *      16384 as soon as we are in normal operation.)
 *
 * The choices of 8000, 10000 and 12000 are completely arbitrary, and can be
 * moved if we run low on OIDs in any category.  Changing the macros below,
 * and updating relevant documentation (see bki.sgml and RELEASE_CHANGES),
 * should be sufficient to do this.  Moving the 16384 boundary between
 * initdb-assigned OIDs and user-defined objects would be substantially
 * more painful, however, since some user-defined OIDs will appear in
 * on-disk data; such a change would probably break pg_upgrade.
 *
 * NOTE: if the OID generator wraps around, we skip over OIDs 0-16383
 * and resume with 16384.  This minimizes the odds of OID conflict, by not
 * reassigning OIDs that might have been assigned during initdb.  Critically,
 * it also ensures that no user-created object will be considered pinned.
 * ----------
 */
#define FirstGenbkiObjectId     10000
#define FirstUnpinnedObjectId   12000
#define FirstNormalObjectId     16384

So:

• OIDs under 10000 are fixed and hard-coded for certain objects

• OIDs under 12000 are system objects that cannot be dropped (with the exception of the public schema and databases)

• OIDs under 16384 are system objects

• the OID generator assigns higher numbers to user objects

See also the documentation on the topic.