Re: [I] ShardingSphere-JDBC got NullPointerException error with postgresql 14 version [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

terrymanu commented on issue #33347:
URL: https://github.com/apache/shardingsphere/issues/33347#issuecomment-3565435140

   • Problem Understanding
   
     - On ShardingSphere-JDBC 5.1.2 with Aurora PostgreSQL 14.11, application user user1 is not the table owner. Querying sharded tables raises an NPE in MyBatis, indicating metadata fetch failure.
   
     Root Cause
   
     - ShardingSphere loads PG metadata by querying information_schema.role_table_grants and information_schema.columns. If the current user lacks explicit privileges on the tables/sequences, these information-
       schema views filter out the tables, so ShardingSphere cannot obtain column/index/constraint metadata, leading to NPE in later binding/result handling.
     - Aurora PostgreSQL 14 behaves like community PostgreSQL 14 for information-schema visibility. Because Aurora has no true superuser (rds_superuser is still constrained by ACL), missing grants more readily
       results in “metadata not visible.”
   
     Analysis
   
     - Grant the connecting user explicit schema/table/sequence privileges. Minimal example (replace schema/table as needed):
   
       GRANT USAGE ON SCHEMA public TO user1;
       GRANT SELECT, REFERENCES ON ALL TABLES IN SCHEMA public TO user1;
       GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO user1;
       ALTER DEFAULT PRIVILEGES FOR ROLE user2 IN SCHEMA public GRANT SELECT, REFERENCES ON TABLES TO user1;
     - Verify visibility using the connecting user:
   
       SELECT table_schema, table_name, privilege_type
       FROM information_schema.role_table_grants
       WHERE grantee = current_user AND table_name = '<logical_table_name>';
   
       SELECT table_schema, table_name
       FROM information_schema.columns
       WHERE table_name = '<logical_table_name>';
       If no rows are returned, privileges are insufficient.
     - ShardingSphere targets standard PostgreSQL semantics; if the target database diverges from standard PG behavior, custom extensions may be needed to adapt to its privilege/catalog behavior.
   
     Conclusion
   
     - The observed NPE stems from missing privileges causing information-schema invisibility, not from a confirmed product defect. Please grant the privileges above and retry.
     - Official documentation: PostgreSQL 14 information schema and visibility https://www.postgresql.org/docs/14/information-schema.html , privilege management https://www.postgresql.org/docs/14/ddl-priv.html .
     - If NPE persists after granting, please share the full stack trace (including ShardingSphere class names) and the results of the two verification queries above for further diagnosis.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org