Skip to Main Content
Forums

Java Database Connectivity (JDBC)

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

12775220 DatabaseMetaData.getColumns() returns unexpected values in COLUMN_SIZE and DECIMAL_DIGITS

Rod AllenFeb 24 2015 — edited Mar 6 2015

Hi All,

I posted a while ago asking about Bug 12775220

I just wanted to provide an update on this as I found a potential solution to the underlying problem that I facing (with NUMBER columns which lacked precision and scale). If you add the JVM argument -Doracle.jdbc.J2EE13Compliant=true it appears to resolve this problem.

Regards


Rod

Comments

If you shutdown mysqld, are the files freed?

3412947
Answer

I am experiencing the same problem and spent the majority of my work day yesterday researching it.  I believe you are hitting a known bug that affected MySQL 5.7.22 - 5.7.25 and 8.0.14 - 8.0.15.  It has been fixed in 5.7.26 and 8.0.16.  Oracle BUG id is 28039829 "File handles are leaked for SELECT queries involving complex joins."  The way MySQL uses on-disk internal temp tables (those produced during a query, not the explicit temporary tables that a user can create), to not leave any temp files behind in case of a server crash, by design MySQL creates the tmp file, and then immediately unlinks it (so it appears to the OS as deleted), but MySQL keeps the descriptor open to the file. You can see this under /proc/{mysqld pid}/fd.  When these work normally, once the thread is done with the temp table, it releases the descriptor and the space and open file are released.   But due to a mistake in file handles that was introduced, it was possible that the descriptors were not being freed.  If you upgrade to the latest release, the problem should go away.  In the meantime, you can workaround (sort of), by setting your max open files higher and giving your tmp location some extra space, and even then you may have to periodically bounce mysqld to reclaim the fds and space.  The bug report has a partial workaround on 8.0.14 & 8.0.15 suggested to set loose_internal_tmp_mem_storage_engine=MEMORY.  For my servers, I run the Percona Server fork, and they have not released their 8.0.16 port (yet as of today), and I eagerly await it.

Marked as Answer by 3837224 · Sep 27 2020
1 person found this helpful
3837224

Yes, I confirm that with upgrade to 8.0.16 the bug has been fixed.

1 person found this helpful
Andy_C

We're having the same problem (8.0.15) - it's a show stopper for us but we have a very extended upgrade time-line so we need a work-around (or work-arounds) that will keep this from occurring until we're able to upgrade (to 8.0.17).

One obvious work-around is to stop and restart mysqld (say weekly) - however, that's kind-of a big deal timing-wise and the problem could still occur between restarts.

In terms of the broken sym-links - does anybody know if it's safe to remove them? That would be an easy, safe, and reliable work-around. I'm thinking that since the files are no longer needed (they were temp files) and are no longer on disk and mysql was supposed to have removed the sym-links anyway it would be ok to run a script periodically to remove them. However, I don't know if mysql would 'object' to them being removed by a non-mysqld process.

Thank you!

Andy

1 person found this helpful
1 - 4
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Apr 3 2015
Added on Feb 24 2015
#java-database-connectivity-jdbc
2 comments
4,068 views