Just did a pull. The upgrade had some problems.
alter table ttrss_archived_feeds add column created datetime
Error: 42S21, 1060, Duplicate column name ‘created’
One of the updates failed. Either retry the process or perform updates manually.
Same here.
Updating dfd3a4e58…69a691f4e
next one to post a content-less “me too” is going to be banned for a year
Not totally sure what you need. Hoping the info in good faith goes in the right direction to not get me banned.
Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-45-generic x86_64)
mysql Ver 14.14 Distrib 5.7.25, for Linux (x86_64) using EditLine wrapper
PHP 7.2.15-0ubuntu0.18.04.1 (cli) (built: Feb 8 2019 14:54:22) ( NTS )
git rev-parse HEAD
69a691f4e13382924d93c85091a2a5f525d1effe
how did you install the schema? because this column hasn’t been added before version 136 so if you’re on 135 it shouldn’t be there.
e: it would be interesting to check if you have any other extra columns. with, i dunno, phpmyadmin or mysql “describe table”.
or mysqldump --no-data -u user ttrss_db -p
Platform and tt-rss versions (i.e. tt-rss git ( 3261dbf ), ubuntu 14.04, mysql, php 5.5) of your server / VDS.
69a691f4e
Ubuntu 18.04.2
PHP 7.0
Mysql 5.7.25-0ubuntu0.18.04.2
Any logs, if you have them and you feel there’s relevant stuff, including:
Couldn’t find any relevant logs from mysql error.log nor preferences after reverting to previous patch.
it would be easy to update the script to drop column if it exists, i’m however very interested WHY it’s there in the first place
do any other tables have created column in particular? other than ttrss_users and ttrss_linked_feeds
I did a pull at ~9am PST. (Before that I did a pull ~8pm last night with no issues. So there was a small number of updates for the 9am pull.) I did not stop the update_daemon2.php during the pull. Then I hit reload in my browser. This pulled up the schema update page. My memory is fuzzy but I think it did 135 and 136, but I’m not positive. Regardless I did no hand manipulation of the schema. This was all automated vie the normal schema update. My first post is were it is now, at 135 but failing 136.
Maybe a difference between the 136.sql between mysql and pgsql?
mysql:
alter table ttrss_archived_feeds change created created bool not null;
pgsql:
alter table ttrss_archived_feeds alter column created set not null;
no, that’s how you set a not null constraint on mysql. also OPs update script fails before this line.
I have a similar issue.
OPs message comes if you retry after a failed update from 135 to 136.
I used the web updater ( …/public.php?op=dbupdate )
The original error is (at least for me)
Performing updates to schema version 136
Updating to version 136
begin
alter table ttrss_archived_feeds add column created datetime
update ttrss_archived_feeds set created = NOW()
alter table ttrss_archived_feeds change created created bool not null
Error: 22003, 1264, Out of range value for column 'created' at row 1
One of the updates failed. Either retry the process or perform updates manually.
I am on master 69a691f4e13382924d93c85091a2a5f525d1effe
I run
ah wtf why is it bool, it should be datetime.
also, how did this work on my mariadb test instance? jesus. how can you convert datetime to bool. 
alright, script has been fixed.
if your database is in inconsistent state (because i don’t think PDO on mysql actually has functional rollback - for whatever reason, i have no idea) do the following to revert back to 135:
alter table ttrss_archived_feeds drop column created;
update ttrss_version set schema_version = 135;
sorry about that. let this be a lesson to me^Wyou - use postgres. 
Heh… I was just running through the schema in my dev environment and it worked… But I copy/pasted it after you just made that last commit.
Yeah… the new updated schema change worked when I run it manually.
maybe it works on mariadb but not on mysql. since there’s no functional transactions first update failed on change column, op retried, and couldn’t add it because it was already there for the first attempt
well that’s my theory 
i’m worried about this lack of rollback though, it’s a real problem
Yeah, I also had both errors and just manually deleted the “created” column it created.
After your change (on c8fc9eee0c5d7a202bd79db41292859c69a79347) it works without problems for me.
Thanks for the fix!
But it’s not like you can really control it. It not reverting the change on a failed commit is outside the scope of TT-RSS.
schema version update is wrapped in a transaction block. it just doesn’t work on mysql.
But without some active [PHP] scripting to check the result of each query, you’d never know whether it worked, and that’s the whole point of transactions. It not working on MySQL sucks, but what else can you do? The whole point of the transaction is all-or-nothing so you don’t have to worry about a failure at one point.
Aren’t most distros shipping MariaDB anyway? You could always update the system requirements to use MariaDB and drop “MySQL” support–even though they are similar. It’s a drastic approach but TT-RSS uses transactions a lot and there’s going to be corruption if this isn’t working.