Postgres error 500 on paths when supplied entity ID gte 2147483647 and lte 9223372036854776832

I think it should be kernel test to catch where id is wrongly converted or passed

In logs I see following

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22003]: Numeric value out of range: 7 ERROR: value "9223372036854775807" is out of range for type integer LINE 4: WHERE "base"."uid" IN ('9223372036854775807') ^: SELECT "base"."uid" AS "uid", "base"."uuid" AS "uuid", "base"."langcode" AS "langcode" FROM "users" "base" WHERE "base"."uid" IN (:db_condition_placeholder_0); Array ( [:db_condition_placeholder_0] => 9223372036854775807 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->getFromStorage() (line 422 of /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

It looks like the error is the same but input IDs are different 9223372036854776831, 9223372036854776832

And the node table
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22003]: Numeric value out of range: 7 ERROR: value "9223372036854775807" is out of range for type integer LINE 5: WHERE "base"."nid" IN ('9223372036854775807') ^: SELECT "revision"."vid" AS "vid", "revision"."langcode" AS "langcode", "revision"."revision_uid" AS "revision_uid", "revision"."revision_timestamp" AS "revision_timestamp", "revision"."revision_log" AS "revision_log", "revision"."revision_default" AS "revision_default", "base"."nid" AS "nid", "base"."type" AS "type", "base"."uuid" AS "uuid", CASE "base"."vid" WHEN "revision"."vid" THEN 1 ELSE 0 END AS "isDefaultRevision" FROM "node" "base" INNER JOIN "node_revision" "revision" ON "revision"."vid" = "base"."vid" WHERE "base"."nid" IN (:db_condition_placeholder_0); Array ( [:db_condition_placeholder_0] => 9223372036854775807 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->getFromStorage() (line 422 of /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Somehow ID for entity using "integer" type but revision table using "bigInt"

db=# \d users
uid	integer		not null	nextval('users_uid_seq'::regclass)
...
db=# \d users_data
uid	bigint		not null	0
...

taxonomy

db=# \d taxonomy_term_data
tid	integer		not null	nextval('taxonomy_term_data_tid_seq'::regclass)
revision_id	bigint			
...
db=# \d taxonomy_term_field_data
tid	bigint		not null	
revision_id	bigint		not null	
...

and node

db=# \d node
nid	integer		not null	nextval('node_nid_seq'::regclass)
vid	bigint			
...
db=# \d node_field_data
nid	bigint		not null	
vid	bigint		not null	
...

I think it major as could lead to data loss

That's because ID is passed to DB as strings

db=# select * from users where uid='9223372036854776831';
ERROR:  value "9223372036854776831" is out of range for type integer
LINE 1: select * from users where uid='9223372036854776831';
                                      ^
db=# select * from users where uid=9223372036854776831;
...
db=# select * from users_field_data where uid='9223372036854776831';
ERROR:  value "9223372036854776831" is out of range for type bigint
LINE 1: select * from users_field_data where uid='922337203685477683...
                                                 ^
db=# select * from users_field_data where uid=9223372036854776831;

Here's smaller test

According to the PostgreSQL documentation the maximum value for an integer value is 2147483647. That PostgreSQL throws an error with SQLSTATE[22003]: Numeric value out of range is for me the right response. That MySQL, MariaDB and SQLite are not doing the same is to me a bit of a disappointment.
If we want to fix this, then what should we do? We have 2 options:
1. Change the database driver for PostgreSQL and make it respond like the other ones. With a try and catch block and then in the catch part test if we have called the database with an integer that was too big and then somehow calculate what the right response should be. To me this is not doable.
2. Change the other database drivers to make it respnd like PostgreSQL. This is something we can do, only it will make those drivers do more more and therefor slower. To me that is not worth it.

It would be better if all by Drupal core supported databases would work in the same way, only they do not. We have 2 options to fix this problem and for me both of them do not result in an exceptable result. Therefor I will close this issue as "won't fix". If somebody has a solution that does not result in bigger problem then it solves, please reopen this issue.

That's actually a duplicate of #3081144: Database primary keys can exceed maximum integer storeable (has actually occurred, in watchdog)

@andypost, how could this duplicate #3081144: Database primary keys can exceed maximum integer storeable (has actually occurred, in watchdog)? The problem described here still exists. Even though #3081144: Database primary keys can exceed maximum integer storeable (has actually occurred, in watchdog) is marked as fixed.

@daffie, this issue is specifically about content entity IDs. So we can fix on entity storage level.

The patch sets upper limit for allowed entity IDs.

The only concern here is possible BC break. MySQL unsigned int has two times bigger range. So that, theoretically there could be Drupal sites that have entity IDs bigger than 2147483647.