View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0035248 | mantisbt | db postgresql | public | 2025-01-18 22:47 | 2025-02-09 07:34 |
Reporter | maximilian70 | Assigned To | dregad | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 2.27.0 | ||||
Target Version | 2.27.1 | Fixed in Version | 2.27.1 | ||
Summary | 0035248: Postgresql Error - db_stats.php - relation "sql_parts" does not exist | ||||
Description | When using "Show database statistics" from /admin/system_utils.php (db_stats.php) with an mantisbt installation v2.27 with a postgresql database one gets the following error:
Environment Details:
With a mysql database the error does not occur. Upon closer inspection of the error and the db_stats.php file I saw that the tables get retrieved by a call to db_get_table_list() which makes a call to $g_db->MetaTables( 'TABLE' ) from ADOdb. It seems all tables are retrieved correctly but when using postgresql the sql_parts table is additionally retrieved. This does not happen when using mysql. This causes the problem because when mantis executes the query to get the stats of the table it does not exist because to access the table correctly "information_schema.sql_parts" has to be used but only sql_parts is in the tables array. However the table should not get retrieved by db_get_table_list() anyway. I also looked into the ADOdb source code and found out that for the pdo_pgsql driver the following query is executed for the MetaTables function:
I executed this query manually using pgAdmin (same user and database as in the config_inc.php) and it only returned the correct tables of mantisbt without the sql_parts table. Therefore I was not able to elaborate what causes the sql_parts tablename to be retrieved by mantis. I think this could be a bug related to version 2.27 because when I downgrade to 2.25.2 (ADOdb Version 5.20.20, Schema Version 213) the error is gone altough I am using the same database. When I upgrade to 2.27 again I also get the error again. | ||||
Steps To Reproduce | The easiest way to reproduce the error is to setup a new mantisbt installation with a new postgresql database.
1.) Setup the described environment | ||||
Additional Information | I stumbled accross this issue while migrating my mantisbt database from mysql to postgresql. I asked for help in the forums where I was told to create a bug report here. Related forum-post: https://mantisbt.org/forums/viewtopic.php?t=33271 | ||||
Tags | No tags attached. | ||||
It looks like the system table 'sql-parts' is now available as of PostgreSQL version 8.2. And probably should be also masked out in the ADODB. In my humble opinion this will not affect the performance of MantisBT in any case, you can ignore this message and move to a new database without worrying. |
|
Thanks for the detailed bug report. I believe @raspopov is correct, this seems to be a bug in ADOdb, which should exclude the Reported upstream: https://github.com/ADOdb/ADOdb/issues/1059
The metaTableSql query executed by ADOdb differs depending on PostgreSQL version, but I believe the version check in ADODB_postgres64::MetaTables()
That is likely due to how ADOdb retrieves PostgreSQL version information (ADODB_postgres64::serverInfo()), which changed in 5.21.0. @maximilian70 Could you please provide the output of |
|
I debugged a little bit and can confirm that it is the ADOdb code and that it has to do with the version check as you assumed. At first I looked in the wrong driver file (adodb-pdo_pgsql.inc.php). I thought it is used because I use php-psql (PHP module pdo_pgsql) on this system. May I ask why adodb-postgres64.inc.php is used instead? I have no experience with php but because of the filename I thought that it is just a really old driver for PostgreSQL 6.4 so I did not look into it at first. As you have already mentioned, the ServerInfo() functions of these two drivers are different, which I did not recognise at first because I only looked at the MetaTables() function.
ADODB_postgres64::serverInfo() returns exactly this string. Therefore the ADODB_pdo_pgsql::serverInfo() returns 15.10 like ADODB_postgres64::serverInfo() did before it got changed in 5.21.0. Therefore the However in the PostgreSQL page of the ADOdb docs it is mentioned that the PostgreSQL drivers are currently undergoing a major refactoring. I hope this fixes the issue in the future. For now I will just ignore the error because in production the admin folder is deleted anyway. (Or if I need the functionality I will just patch the code manually so that sql_parts gets removed from the retrieved tables array) Thanks for your help. Kind regards |
|
@maximilian70 thanks for the feedback.
This is a legacy thing. When PostgreSQL support was added to MantisBT via ADOdb, PDO did not even exist (it was introduced in PHP 5.1 IIRC).
Exactly what I suspected. Thanks for the confirmation.
Correct, see https://github.com/ADOdb/ADOdb/pull/1008 But fixing this regression does not need to wait for the refactoring to be complete, it's a simple and straightforward change, that will be treated as a hot fix and released soon. |
|