Unable to install because table ultimate_cron_signal has an index too long

It looks like the change introduced in fc3cbbe is not compatible with PostgreSQL. When applying database updates from the latest 7.x-2.0rc2 it throws the following errors:

Notice: Array to string conversion en DatabaseSchema_pgsql->addUniqueKey() (line 464 of /var/www/public_html/includes/database/pgsql/schema.inc).

And in the update.php page:

The following updates returned messages
ultimate_cron module
Update #7203

Failed: PDOException: SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "Array" LINE 1: ...STRAINT "ultimate_cron_lock_idx_name_key" UNIQUE (Array,curr... ^: ALTER TABLE {ultimate_cron_lock} ADD CONSTRAINT "ultimate_cron_lock_idx_name_key" UNIQUE (Array,current); Array ( ) en db_add_unique_key() (línea 2918 de /var/www/public_html/includes/database/database.inc).

Since the update process halts after deleting the ultimate_cron_log index, I had to manually modify the lines of the update, and run it again to recreate it:

/**
 * Fix index sizes.
 */
function ultimate_cron_update_7203() {
  db_drop_index('ultimate_cron_log', 'idx_last');
  db_add_index('ultimate_cron_log', 'idx_last', array(
    'name',
    'start_time',
    'end_time',
    'log_type',
  ));
  db_drop_unique_key('ultimate_cron_lock', 'idx_name');
  db_add_unique_key('ultimate_cron_lock', 'idx_name', array(
    'name',
    'current',
  ));
  db_drop_primary_key('ultimate_cron_signal');
  db_add_primary_key('ultimate_cron_signal', array(
    'job_name',
    'signal_name',
  ));
}

Let me know if I can do further testing for you.

This is an issue for new installs (Drupal version 7.43, enable via drush, Postgresql 9.3.12) as well:

WD php: PDOException: SQLSTATE[42601]: Syntax error: 7 ERROR:  syntax error[error] at or near "Array"
LINE 7: ...ONSTRAINT ultimate_cron_lock_idx_name_key UNIQUE (Array, cur...
                                                             ^: CREATE
TABLE {ultimate_cron_lock} (
	lid bigserial,
	name varchar(255) NOT NULL,
	current bigint NOT NULL default 0,
	expire double precision NOT NULL default 0,
	PRIMARY KEY (lid),
	CONSTRAINT ultimate_cron_lock_idx_name_key UNIQUE (Array, current)
); Array
(
)
 in db_create_table() (line 2720 of
/data/www/html/moduletesting_meg/drupal-7.43/includes/database/database.inc).
Cannot modify header information - headers already sent by (output started [warning]
at /usr/share/pear/drush/includes/output.inc:38) bootstrap.inc:1232
PDOException: SQLSTATE[42601]: Syntax error: 7 ERROR:  syntax error at or near "Array"
LINE 7: ...ONSTRAINT ultimate_cron_lock_idx_name_key UNIQUE (Array, cur...
                                                             ^: CREATE TABLE {ultimate_cron_lock} (
	lid bigserial,
	name varchar(255) NOT NULL,
	current bigint NOT NULL default 0,
	expire double precision NOT NULL default 0,
	PRIMARY KEY (lid),
	CONSTRAINT ultimate_cron_lock_idx_name_key UNIQUE (Array, current)
); Array
(
)
 in db_create_table() (line 2720 of /data/www/html/moduletesting_meg/drupal-7.43/includes/database/database.inc).
Drush command terminated abnormally due to an unrecoverable error.         [error]

I just ran into this when trying to import a new dump of my database into my test environment. It total hosed the sql import with:

Error in query (1071): Specified key was too long; max key length is 1000 bytes

A fix for this is still needed.

Correct me if I'm wrong, but I'm not sure why this 1000B thing is a bug that needs fixing in the module...

The MySQL documentation states:

The InnoDB internal maximum key length is 3500 bytes, but MySQL itself restricts this to 3072 bytes. This limit applies to the length of the combined index key in a multi-column index.

If you reduce the InnoDB page size to 8KB or 4KB by specifying the innodb_page_size option when creating the MySQL instance, the maximum length of the index key is lowered proportionally, based on the limit of 3072 bytes for a 16KB page size. That is, the maximum index key length is 1536 bytes when the page size is 8KB, and 768 bytes when the page size is 4KB.

The [MyISAM] maximum key length is 1000 bytes. This can also be changed by changing the source and recompiling.

Therefore, given that Drupal defaults to using InnoDB and InnoDB defaults to a 16KB page size, isn't this a server configuration issue and down to a server admin to resolve?

Furthermore, commit fc3cbbe in #3 added prefix lengths to various indexes and keys which as far as I can see, weren't causing any problems the way they were before. That change now makes them useless for sorting/grouping queries (which ignore indexes with prefix lengths) and is partly contributing to a separate issue over in #2379871-34: White Screen of Death on admin/config.

EDIT: Wrong ticket ... 2 sec...

I think it could be an idea to reduce the actual column size of the job_name, signal_name and lock_name in order for mysql to accept the compound primary key (job_name, signal_name) in the signals table.

Reducing the size of the index has 2 problems:
- performance-hit as seen in this #2379871: White Screen of Death on admin/config.
- doesn't work on postgres (and possibly others)

I'm thinking a size of 128 each for all three. Any thoughts?

Fixed (by @gielfeldt) in 7.x-2.0-rc4.