Tiny Tiny RSS: Community

Database initialization hangs

Describe the problem you’re having:

Database initialization on installation hangs on “Query: insert into ttrss_feeds (owner_uid, title, feed_url) values (1, ‘Tiny Tiny RSS: Forum’, ‘’)” (Link removed by me so I can post)

If possible include steps to reproduce the problem:

  1. Open installer
  2. Enter database credentials
  3. Click “Test configuration”
  4. Click “Initialize database”

tt-rss version (including git commit id):

Latest master, git commit f6090655bf

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:

Ubuntu 18.04 LTS
PHP 7.3.11 (self-compiled)
MariaDB 10.3.18

Please provide any additional information below:

PHP Fatal error: Uncaught Error: Using $this when not in object context in /srv/www/feedreader.example.com/install/index.php:440

Created tables:

ttrss_users contains the admin user. No other tables contain data.

Looks like line 440 should be …$pdo->errorInfo()… But that’s incidental because that line is only called if the query failed.

You can manually drop the database and import the schema through the command line; at least until this bug is patched; it will work just as well and you’ll probably be able to see the real error that way.

Since there’s no actual MySQL error provided here I can’t really provide much more in the way of assistance. If you can post back with an actual database error it will help us resolve that issue.

e: Pull request to patch the fatal error issue: https://git.tt-rss.org/fox/tt-rss/pulls/125

merged, thanks.


Now I get:

Query: insert into ttrss_feeds (owner_uid, title, feed_url) values (1, 'Tiny Tiny RSS: Forum', 'http://tt-rss.org/forum/rss.php')

Error: 23000, 1452, Cannot add or update a child row: a foreign key constraint fails (`feedreader`.`ttrss_feeds`, CONSTRAINT `ttrss_feeds_ibfk_1` FOREIGN KEY (`owner_uid`) REFERENCES `ttrss_users` (`id`) ON DELETE CASCADE)

Database initialization completed.

After that I can write the configuration file and Tiny Tiny RSS seems to be working (but I have just tested logging in and clicking a little bit around).

that’s weird. you were able to login so I assume you have an admin user (id=1) but a query referencing it failed for some reason. haven’t seen this before.

i would import the schema again, from the command line, just to be sure.

Yes, admin user has been created.

Same error when importing from command line with:

mysql -u feedreader -p feedreader < ttrss_schema_mysql.sql

Import only works if I disable foreign key checking:


Database ist MariaDB 10.4.9 (updated from 10.3.18 today) with Galera Cluster and three nodes. Never had issues.

well, i don’t see anything wrong with that particular insert, so someone else who knows more about mysql should have to investigate.

my guess would be devs changing or breaking something arbitrarily. won’t be the first time.

I was able to import the schema into a new, empty database without issue. But I’m running MariaDB 10.1.41 in my dev environment.

I’m going to guess the error is because of the begin and commit lines. Because it’s doing all this as a single transaction, I bet that breaks it. Unfortunately, because I can’t re-create the issue I can’t confirm.

I tried importing the schema without the begin and commit lines, but the same error occurs.

i think mysql commits everything implicitly on table structure change (as opposed to postgres).

Well, if you’re willing to test this for us, what would happen if you imported the schema up to line 60 (deleting everything after the insert into ttrss_users … part). Then run:

SELECT id, login FROM ttrss_users;

And report the results.

Yeah… It just seemed like the kind of error MySQL would throw. :man_shrugging:

It does: https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html

13.3.3 Statements That Cause an Implicit Commit

The statements listed in this section (and any synonyms for them) implicitly end any transaction active in the current session, as if you had done a COMMIT before executing the statement.

Most of these statements also cause an implicit commit after executing.

Data definition language (DDL) statements that define or modify database objects […]

Done, result:

MariaDB [ttrsstest]> SELECT id, login FROM ttrss_users;
| id | login |
|  2 | admin |
1 row in set (0.001 sec)

I think we see the problem :slight_smile: With Galera Cluster the id is not increased one by one and, as you can see, not even starting with 1. This is by design to avoid conflicts. But the “problem query” relies on the id starting with 1.

Do not rely on auto-increment values to be sequential. Galera uses a mechanism based on autoincrement increment to produce unique non-conflicting sequences, so on every single node the sequence will have gaps.

that explains it. schema should probably be fixed to not use hardcoded uid in that insert, instead doing nested select or something.

i’m not sure if there are other places in code where admin UID is supposed to be 1. single user mode, if that is still supported. maybe something else.

e: https://git.tt-rss.org/fox/tt-rss/commit/60609637bc0301bc89bf00453273302a2126689d