فشل التحديث على db_migrate

I am trying to update my discource instance from 2.9.0.beta10 to 3.2.0.beta1.
I am getting error like this

Tasks: TOP => db:migrate
(See full trace by running task with --trace)
I, [2023-09-15T02:32:08.512373 #1]  INFO -- : Compiled js-processor: tmp/js-processor.js
== 20230118020114 AddPublicTopicCountToTags: migrating ========================
-- add_column(:tags, :public_topic_count, :integer, {:default=>0, :null=>false})
   -> 0.0021s
-- execute("UPDATE tags t\nSET public_topic_count = x.topic_count\nFROM (\n  SELECT\n    COUNT(topics.id) AS topic_count,\n    tags.id AS tag_id\n  FROM tags\n  INNER JOIN topic_tags ON tags.id = topic_tags.tag_id\n  INNER JOIN topics ON topics.id = topic_tags.topic_id AND topics.deleted_at IS NULL AND topics.archetype != 'private_message'\n  INNER JOIN categories ON categories.id = topics.category_id AND NOT categories.read_restricted\n  GROUP BY tags.id\n) x\nWHERE x.tag_id = t.id\nAND x.topic_count <> t.public_topic_count;\n")

I, [2023-09-15T02:32:08.512848 #1]  INFO -- : Terminating async processes
I, [2023-09-15T02:32:08.512929 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 42
I, [2023-09-15T02:32:08.513001 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 111
111:signal-handler (2023-09-15 02:32:08.513 UTC [42] LOG:  received fast shutdown request
1694745128) Received SIGTERM scheduling shutdown...
2023-09-15 02:32:08.522 UTC [42] LOG:  aborting any active transactions
2023-09-15 02:32:08.524 UTC [42] LOG:  background worker "logical replication launcher" (PID 51) exited with exit code 1
2023-09-15 02:32:08.526 UTC [46] LOG:  shutting down
111:M 15 Sep 2023 02:32:08.532 # User requested shutdown...
111:M 15 Sep 2023 02:32:08.532 * Saving the final RDB snapshot before exiting.
2023-09-15 02:32:08.768 UTC [42] LOG:  database system is shut down
111:M 15 Sep 2023 02:32:11.475 * DB saved on disk
111:M 15 Sep 2023 02:32:11.475 # Redis is now ready to exit, bye bye...


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 787 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}

Any idea what is wrong ?
I did update my instance previusly without errors.
Discoruce doctor did not let me any clues to search for.


Does upper message reffers this sql stantmet

UPDATE tags t
SET public_topic_count = x.topic_count
FROM (
	SELECT    COUNT(topics.id) AS topic_count,    
	tags.id AS tag_id
	FROM tags
	INNER JOIN topic_tags ON tags.id = topic_tags.tag_id
	INNER JOIN topics ON topics.id = topic_tags.topic_id AND topics.deleted_at IS NULL AND topics.archetype != 'private_message'
	INNER JOIN categories ON categories.id = topics.category_id AND NOT categories.read_restricted
	GROUP BY tags.id
) x
	WHERE x.tag_id = t.id
	AND x.topic_count <> t.public_topic_count;

Becuse If I runn in db directly only code in select I do not get errors,
I see that db:migrate job first add cloumn by
add_column(:tags, :public_topic_count, :integer, {:default=>0, :null=>false})
No idea why then fail on upper query ?

Is there a message at the bottom of the log saying “scroll up and look for earlier error messages”? If so, are you finding any other error messages?

إعجابَين (2)

Thank you for tip, there was error before this. I really should stop updating servers after midnight my resources are low in that time.


Anyway for future readers:
Error was produced because somehow we had in table tags multiple rows with same value in column name.
After deleting tags with duplicated rows upgrade went smoothly.

3 إعجابات

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.