Project

General

Profile

Development #54658

possibilité pour une mise à jour des données de se casser et laisser un schéma vide

Added by Frédéric Péters 9 days ago. Updated 4 days ago.

Status:
Nouveau
Priority:
Normal
Target version:
-
Start date:
08 Jun 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

    def do_schema(self):
        self.ex('SET search_path = public')
        self.logger.debug('dropping schema %s', self.schema_temp)
        self.drop_tables_sequencially(self.schema_temp)
        self.ex('DROP SCHEMA IF EXISTS {schema_temp} CASCADE')
        self.logger.debug('creating schema %s', self.schema)
        self.ex('CREATE SCHEMA {schema_temp}')
        self.ex('SET search_path = {schema_temp},public')

Le drop_tables_sequencially peut échouer, ex:

  File "/usr/lib/python3/dist-packages/wcs_olap/cmd.py", line 108, in main2
    olap_feeder.feed()
  File "/usr/lib/python3/dist-packages/wcs_olap/feeder.py", line 619, in feed
    self.drop_tables_sequencially(self.schema)
  File "/usr/lib/python3/dist-packages/wcs_olap/feeder.py", line 368, in drop_tables_sequencially
    % (quote(schema), quote(table_name), quote(constraint_name)))
  File "/usr/lib/python3/dist-packages/wcs_olap/feeder.py", line 336, in ex
    self.cur.execute(sql, vars=vars)
psycopg2.extensions.TransactionRollbackError: deadlock detected
DÉTAIL : Process 2936 waits for AccessExclusiveLock on relation 825879306 of database 50671; blocked by process 25139.
Process 25139 waits for AccessShareLock on relation 825902239 of database 50671; blocked by process 2936.
ASTUCE : See server log for query details.

et le résultat derrière c'est une base sans (toutes) les données/tables nécessaires.


Files

Associated revisions

Revision c74766bf (diff)
Added by Benjamin Dauvergne 9 days ago

feeder: set deadlock_timeout to 10 seconds (#54658)

It makes wcs-olap always win in a deadlock with another client.

Revision b3a59edb (diff)
Added by Benjamin Dauvergne 4 days ago

Revert "feeder: set deadlock_timeout to 10 seconds (#54658)"

This reverts commit c74766bf2c7a911ab04da9084231ef3397cb2964.

History

#2

Updated by Benjamin Dauvergne 9 days ago

Le deadlock_timeout est à une seconde par défaut, pour toutes les transactions, je pense qu'on peut le pousser à 10s durant la mise à jour olap.

#3

Updated by Benjamin Dauvergne 9 days ago

  • Assignee set to Benjamin Dauvergne
#4

Updated by Benjamin Dauvergne 9 days ago

#6

Updated by Benjamin Dauvergne 8 days ago

Benjamin Dauvergne a écrit :

Autant modifier le timeout le plus tôt possible.

Le but si ce n'est pas clair c'est que dans un duel (due à la détection des deadlock par postgresql), ce soit toujours wcs-olap qui gagne vu que sont timeout est plus élevé; ça laisse toujours une marge d'erreur car le scheduling des processus peut faire que wcs-olap perde quand même mais 10s ça laisse quand même une bonne marge.

#7

Updated by Nicolas Roche 8 days ago

  • Status changed from Solution proposée to Solution validée
#8

Updated by Benjamin Dauvergne 7 days ago

  • Status changed from Solution validée to Résolu (à déployer)
commit c74766bf2c7a911ab04da9084231ef3397cb2964
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date:   Tue Jun 8 17:24:52 2021 +0200

    feeder: set deadlock_timeout to 10 seconds (#54658)

    It makes wcs-olap always win in a deadlock with another client.
#9

Updated by Frédéric Péters 6 days ago

  • Status changed from Résolu (à déployer) to Solution déployée
#10

Updated by Frédéric Péters 4 days ago

  • Patch proposed changed from Yes to No
  • Status changed from Solution déployée to Nouveau

Le commit étant annulé (#54808) ce ticket reste.

Also available in: Atom PDF