Bug #4090: The migration script dbMigration-2.6-2.6-index-reports.sql could take a lots of minutes - Rudder - Issue Tracker

Actions

Copy link

Bug #4090

closed

The migration script dbMigration-2.6-2.6-index-reports.sql could take a lots of minutes

Added by Nicolas PERRON about 11 years ago. Updated over 9 years ago.

Status:

Rejected

Priority:

Assignee:

Nicolas CHARLES

Category:

Packaging

Target version:

2.6.20

Pull Request:

Severity:

UX impact:

User visibility:

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

During an upgrade of rudder-web package (from 2.6.2 to 2.6.8 on my case) the rudder-upgrade script is launched.
From rudder-upgrade, one of the PostgreSQL script, named dbMigration-2.6-2.6-index-reports.sql, is launched but takes too many time.

This script could take more than 30 minutes ! (Too bad, I can't reproduce to estimate)

A message should warn of the script should not be automatically launched.

Actions

Copy link

Updated by Nicolas PERRON about 11 years ago

Target version changed from 2.6.9 to 2.6.10

Actions

Copy link

Updated by Nicolas CHARLES almost 11 years ago

I'm not sure I understand what you want.
Is that in case of upgrade, the post-install script should not be launched ?

There is already an info saying:
INFO: Updating the PostgreSQL indexes, this may take several minutes...

isn't that enough ?

Actions

Copy link

Updated by Vincent MEMBRÉ almost 11 years ago

Target version changed from 2.6.10 to 2.6.11

Actions

Copy link

Updated by Nicolas PERRON almost 11 years ago

Status changed from New to Discussion
Assignee set to Nicolas CHARLES

If I remind well, the problem was that upgrading a package during more than 30 min is so long that it could be let users think that the rpm installation is frozen without timeout (like I thought during this upgrade).
I don't remember any INFO message but I still think that upgrading a package during 30min-1hour is disturbing, don't you ?

Actions

Copy link

Updated by Nicolas CHARLES almost 11 years ago

but we need this script to run, or else the perfs will be catastrophics
What do you suggest we should do?

Actions

Copy link

Updated by Nicolas PERRON over 10 years ago

Nicolas CHARLES wrote:

but we need this script to run, or else the perfs will be catastrophics
What do you suggest we should do?

Maybe a PSQL request to gauge if the update will be very long or not and if this is the case to warn the user that it will take very long, not interruption should be done.

The request could be for example:
- "SELECT reltuples FROM pg_class WHERE relname='ruddersysevents'" to estimate number of rows
- "SELECT pg_size_pretty(pg_total_relation_size('ruddersysevents'));" to know the size of the table and if it is more than 10GB I suppose the script will be quite slow

Actions

Copy link