Error in Upgrade from 1.10.12 to 1.13.29-1

Yeti installation and upgrade
1

I’ve built several test clusters to allow us to upgrade to a current version of Yeti.

I tried to update our database today and got the following error

2025-08-14 17:08:12.501229 I [9890:29280] ActiveRecord::Base -- Migrating to NewRtpStatistics (20220426100841)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled: (StandardError)

PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint "queue_pkey"
DETAIL:  Key (queue_id)=(1) already exists.
CONTEXT:  SQL statement "insert into pgq.queue (queue_id, queue_name,
            queue_data_pfx, queue_event_seq, queue_tick_seq)
        values (id, i_queue_name, tblpfx, ev_seq, tick_seq)"
PL/pgSQL function pgq.create_queue(text) line 46 at SQL statement

How should I work around this?

Once again, thanks for your support.

Paul

2 
yeti=# SELECT * from pgq.queue;
-[ RECORD 1 ]------------+------------------------------
queue_id                 | 1
queue_name               | gateway-sync
queue_ntables            | 3
queue_cur_table          | 1
queue_rotation_period    | 02:00:00
queue_switch_step1       | 3433487
queue_switch_step2       | 3433489
queue_switch_time        | 2020-06-17 17:20:42.246016+10
queue_external_ticker    | f
queue_disable_insert     | f
queue_ticker_paused      | f
queue_ticker_max_count   | 500
queue_ticker_max_lag     | 00:00:03
queue_ticker_idle_period | 00:01:00
queue_per_tx_limit       |
queue_data_pfx           | pgq.event_1
queue_event_seq          | pgq.event_1_id_seq
queue_tick_seq           | pgq.event_1_tick_seq
queue_extra_maint        |
4
1 Like
5

Much thanks - that appeared to be the issue.

On the fourth try it got past that, and now I’m seeing this:

PG::InvalidParameterValue: ERROR:  extension "yeti" has no update path from version "1.3.9" to version "1.3.4"

More detail:

== 20220717150840 CnameLua: migrating =========================================
-- execute("\n\n      alter extension yeti update TO \"1.3.4\";\n      alter table class4.customers_auth add cnam_database_id smallint references class4.cnam_databases(id);\n      alter table class4.customers_auth_normalized add cnam_database_id smallint;\n      alter table class4.cnam_databases\n
add response_lua varchar,\n        add request_lua varchar,\n        add drop_call_on_error boolean not null default false;\n            ")
2025-08-15 09:09:35.760648 I [19000:29280] ActiveRecord::Base -- Migrating to CnameLua (20220717150840)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled: (StandardError)

PG::InvalidParameterValue: ERROR:  extension "yeti" has no update path from version "1.3.9" to version "1.3.4"

yeti=# select * from pg_extension where extname = 'yeti';
-[ RECORD 1 ]--+------
oid            | 17343
extname        | yeti
extowner       | 10
extnamespace   | 16606
extrelocatable | t
extversion     | 1.3.9
extconfig      |
extcondition   |
6

I’ll try a few more times but I think this is going to get very stuck.

Tried another 5 times, never got past this. :frowning:

When I start up Yeti and try to log in, I get this error:

ERROR:  relation "billing.service_types" does not exist

yeti=# select * from billing.service_types;
ERROR:  relation "billing.service_types" does not exist

yeti=# select * from billing.
billing.accounts                   billing.cdr_batches                billing.invoice_periods_id_seq     billing.invoices_templates_id_seq  billing.payments_id_seq
billing.accounts_id_seq            billing.invoice_periods            billing.invoice_templates          billing.payments
7

you already installed latest version so it can’t downgrade.
Try to comment alter extension yeti update... in migration file.

8

WIll do.

It looks like the CDR DB upgrades successfully, but the Yeti/Routing DB is causing trouble.

I’m a bit worried about why it’s trying to downgrade, but I’ll test and let you know.

From our current Production box - Yeti 1.10.12

 extname | extversion
---------+------------
 yeti    | 1.3.3
9

I edited 20220717150840_cname_lua.rband 20220805080124_process_diversion.rb, which allowed the migration to get past that.

The latest error is

cannot drop column balance_low_threshold of table accounts because other objects depend on it

Caused by 20221015082627_create_account_balance_notification_settings.rb

I’ll run the upgrade a few more times to see if it gets past that, but I’m not sure it will.

Full error

2025-08-18 14:56:21.690474 I [60227:worker-1] Rails -- sentry -- Unreported Event: PG::DependentObjectsStillExist: ERROR:  cannot drop column balance_low_threshold of table accounts because other objects depend on it (PG::DependentObjectsStillExist)
DETAIL:  view v_billing_accounts depends on column balance_low_threshold of table accounts
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
10

There is no such view in yeti databases. It means structure of your database was manually modified and differs from what yeti expects. You have to revert such modifications first.

1 Like
11

Thank you, I’ve removed the foreign views and managed to get a few steps futher.

The next issue I’ve encountied is:

PG::ForeignKeyViolation: ERROR:  insert or update on table "gateways" violates foreign key constraint "gateways_termination_dst_numberlist_id_fkey" (PG::ForeignKeyViolation)
DETAIL:  Key (termination_dst_numberlist_id)=(883) is not present in table "numberlists".

I ran the migrate a few times but didn’t get past this

I’ll look in the DB and see if I can provide further feedback

This looks like a DB inconsistancy - I’ll see if I can update the Gateway in the IU to resolve the issue

select id,termination_dst_numberlist_id from class4.gateways WHERE termination_dst_numberlist_id = 883;
 id  | termination_dst_numberlist_id
-----+-------------------------------
 220 |                           883

select id,created_at from class4.numberlists where id > 880 and id < 889;
 id  |          created_at
-----+-------------------------------
 881 | 2022-04-27 08:53:26.00276+10
 882 | 2022-04-27 08:53:32.60485+10
 886 | 2022-05-06 12:14:09.39765+10
 887 | 2022-05-11 11:25:41.486707+10
 888 | 2022-05-11 13:38:31.850265+10
(5 rows)

I’m working on these problematic items - looks like staff deleted numberlists that were attached to gateways

12

There is no information what migration failing and what statement causing problem.

1 Like
13

All good - it’s old data and I’m cleaning it up.

It’s where gateways had a numberlist attached and the numberlist was deleted.

I wrote a query to locate the gateways. Opening and saving them without changes fixed them.

SELECT termination_dst_numberlist_id FROM class4.gateways
EXCEPT SELECT id FROM class4.numberlists;
14

@dmitry.s
Thank you for help with this - yesterday I migrated out production DB to the Lab and it’s now attached to my Yeti 13 testing system.