Project

General

Profile

Actions

Bug #4090

closed

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

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

Status:
Rejected
Priority:
3
Category:
Packaging
Target version:
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 #1

Updated by Nicolas PERRON over 10 years ago

  • Target version changed from 2.6.9 to 2.6.10
Actions #2

Updated by Nicolas CHARLES over 10 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 #3

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.6.10 to 2.6.11
Actions #4

Updated by Nicolas PERRON about 10 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 #5

Updated by Nicolas CHARLES about 10 years ago

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

Actions #6

Updated by Nicolas PERRON about 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 #7

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.6.11 to 2.6.12
Actions #8

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.6.12 to 2.6.13
Actions #9

Updated by Vincent MEMBRÉ almost 10 years ago

  • Target version changed from 2.6.13 to 2.6.14
Actions #10

Updated by Jonathan CLARKE almost 10 years ago

  • Target version changed from 2.6.14 to 2.6.16
Actions #11

Updated by Jonathan CLARKE almost 10 years ago

  • Target version changed from 2.6.16 to 2.6.17
Actions #12

Updated by Nicolas PERRON over 9 years ago

  • Target version changed from 2.6.17 to 2.6.18
Actions #13

Updated by Matthieu CERDA over 9 years ago

  • Target version changed from 2.6.18 to 2.6.19
Actions #14

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 2.6.19 to 2.6.20
Actions #15

Updated by François ARMAND about 9 years ago

  • Status changed from Discussion to Rejected

2.6 is no more supported (nor that migration script)

Actions #16

Updated by Benoît PECCATTE about 9 years ago

  • Project changed from 34 to Rudder
  • Category set to Packaging
Actions

Also available in: Atom PDF