Time Nick Message 03:08 mtj hi Joubu: ive uploaded a Data::Session pkg, re bug 17427 03:08 huginn Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17427 normal, P5 - low, ---, jonathan.druart+koha, Needs Signoff , Replace CGI::Session with Data::Session 09:20 cait tuxayo: hm maybe via the developer tools? 09:20 cait that's how i did it in the past 09:20 cait when testing without javascript 09:34 tuxayo cait: I tried with those tools to mess with JS and the HTML/DOM but couldn't find what to mess with to disable validation 09:35 tuxayo Without JS the form doesn't show ^^" 09:44 cait oh 16:06 JStal Hello! Just discovered that our import_records table is 1.4GiB (!). Ran cleanup_database.pl --z3950 to clear it, expecting the table to truncate to a smaller size, but that didn't happen. Attempting to truncate through phpMyAdmin yields a foreign key error—what should I do to clean this up? 16:30 tuxayo hi JStal :) 16:31 tuxayo Did the number of records from the table decreased with the cleanup? 16:31 JStal Hi! They did—the table has zero records now. 16:35 tuxayo JStal: that's actually surprising, --z3950 should not purge this table 16:35 tuxayo https://git.koha-community.org/Koha-community/Koha/src/branch/master/misc/cronjobs/cleanup_database.pl#L708 16:40 JStal Interesting! You're right—my import_batches table is also clear. We don't often use the import function, instead relying on z39.50, so the import_batches table isn't very large. This post from Bywater indicates that cleanup might clear the import_records table, too? https://bywatersolutions.com/news/losing-weight-koha 16:44 JStal "There’s also a hidden side to import_records. When you search another catalog using Z39.50 from the staff client, every record that gets returned is also stored in import_records. ... A recent update to Koha added the “–z3950†option to cleanup_database, which will purge all records coming from Z39.50 sources." 16:45 JStal After switching to koha-shell and exporting PERL5LIB and KOHA_CONF I ran "perl /usr/share/koha/bin/cronjobs/cleanup_database.pl --z3950 --confirm" specifically. This may be the intended outcome, but I'm surprised that the table isn't truncated. 16:56 tuxayo JStal: so both table got their records purged? 16:56 tuxayo the post doesn't mention import_batches so i'm confused 16:56 tuxayo also 16:56 tuxayo https://git.koha-community.org/Koha-community/Koha/src/branch/master/misc/cronjobs/cleanup_database.pl#L676 16:56 tuxayo PurgeImportTables should help 16:58 tuxayo https://mariadb.com/kb/en/optimize-table/ 16:58 tuxayo https://mariadb.com/kb/en/defragmenting-innodb-tablespaces/ 16:58 tuxayo ↑↑ maybe it's the actual issue 16:58 cait i seem to remember that the dbms doesn't give the space up 16:58 cait when you truncate a table 16:59 cait tuxayo: is that what you were pointing out? 17:00 tuxayo cait: it's seems to be that. I did know there was that behaviour until searching that now. 17:01 cait I usually don't deal with that - just remember something our admin told me 17:05 JStal Sorry, I must have misunderstood. I thought the first link was demonstrating that the cleanup_database shouldn't clear import_records (but import_batches instead) with the --z3950 command. Line 676 seems to support that, but I only ran the command once, and the import_records table is now empty (but still large). 17:08 JStal From https://mariadb.com/kb/en/defragmenting-innodb-tablespaces/: "Note that tablespace files (including ibdata1) will not shrink as the result of defragmentation, but one will get better memory utilization in the InnoDB buffer pool as there are fewer data pages in use." 17:09 JStal Will this shrink the table on disk? I'm mostly concerned about speed, but that table is larger than every other table combined several times. 17:11 tuxayo > but I only ran the command once, and the import_records table is now empty 17:11 tuxayo I don't know why both the cleaned. That's the odd thing right? 17:11 tuxayo *both got cleaned 17:12 tuxayo > Note that tablespace files (including ibdata1) will not shrink as the result of defragmentation 17:12 tuxayo I guess it's OPTIMIZE TABLE that fits, then 17:13 JStal Definitely odd. 17:13 JStal From OPTIMIZE: Note that tablespace files (including ibdata1) will not shrink as the result of defragmentation, but one will get better memory utilization in the InnoDB buffer pool as there are fewer data pages in use. 17:13 tuxayo I forgot to say that don't have experience with all of this ^^" Just finding stuff that seems to fit the current use case 17:19 JStal Oh, you've definitely moved me further than I was! I appreciate it. My searches were all Koha-specific, so I'll broaden them.