The access_db_check table was created solely to detect this error and prevent it from causing further damage to the database indexes by preventing Artifactory from starting up.
The access_db_check table has two columns - username and sorting_order where username is of type character varying(15) and sorting_order is an integer.
username | sorting_order
----------+---------------
0102 | 1
"0102" | 2
Column | Type | Collation | Nullable | Default
---------------+-----------------------+-----------+----------+---------
username | character varying(15) | | not null |
sorting_order | integer | | not null |
Indexes:
"access_db_check_pk" PRIMARY KEY, btree (username)
This table is configured in a way that allows us to determine whether the indexes in the database are properly defined or not (based on the database collation and the table content) and in case they are not, an error will be thrown.
The reason for this error and architectural design is the known glibc library version issue - documented extensively here.
The access_db_check table has two columns - username and sorting_order where username is of type character varying(15) and sorting_order is an integer.
username | sorting_order
----------+---------------
0102 | 1
"0102" | 2
Column | Type | Collation | Nullable | Default
---------------+-----------------------+-----------+----------+---------
username | character varying(15) | | not null |
sorting_order | integer | | not null |
Indexes:
"access_db_check_pk" PRIMARY KEY, btree (username)
This table is configured in a way that allows us to determine whether the indexes in the database are properly defined or not (based on the database collation and the table content) and in case they are not, an error will be thrown.
The reason for this error and architectural design is the known glibc library version issue - documented extensively here.