Hi @angober,
I imagine this happened after an upgrade?
This column is added by the alter statement in this file:
/opt/kaltura/app/deployment/updates/sql/2017_05_15_add_type_column_sphinx_log.sql
And should have been executed when running:
php $KALTURA_PREFIX/app/deployment/updates/update.php -i -d >> /opt/kaltura/log/kalt_up.log 2>&1
php $KALTURA_PREFIX/app/deployment/updates/update.php -i -s >> /opt/kaltura/log/kalt_up.log 2>&1
which is triggered from the kaltura-base postinst hook.
Can you check for errors in /opt/kaltura/log/kalt_up.log for errors?
In this particular case, older deployments did not correctly set up the privileges for the kaltura_sphinx_log DB and for that reason, the following statements were also added to the %post hook in the event of an upgrade:
https://github.com/kaltura/platform-install-packages/blob/Mercury-13.7.0/RPM/SPECS/kaltura-base.spec#L245-#L246
Can you try to manually run these and see if they pass correctly?
You didn’t mention whether you are using the RPM or deb packages, for deb, this is done here:
https://github.com/kaltura/platform-install-packages/blob/Mercury-13.7.0/deb/kaltura-base/debian/postinst#L66-#L67
and you can find them under /var/lib/dpkg/info/kaltura-base.postinst.
Thanks,