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 3 months ago. Updated about 1 month ago.

Status:
Solution déployée
Priority:
Normal
Target version:
-
Start date:
08 Jun 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
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


Related issues

Related to OLAP / Business Intelligence pour Publik - Bug #54808: pas de permissions pour SET deadlock_timeoutRésolu (à déployer)14 Jun 2021

Actions

Associated revisions

Revision c74766bf (diff)
Added by Benjamin Dauvergne 3 months 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 3 months ago

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

This reverts commit c74766bf2c7a911ab04da9084231ef3397cb2964.

Revision 05c40317 (diff)
Added by Benjamin Dauvergne about 1 month ago

feeder: prevent situation of half-dropped schema (#54658)

To prevent loosing currently loaded data wcs-olap, failing ro rename the
temporary schema to its final name, wcs-olap will:

- first, inside a transaction, rename the current schema instead of
dropping it, then rename the new schema to the current schema's name;
in case of failure it will retry 33 times sleeping 1 second between
each attempt;

- if successfull, drop the renamed old schema, again in a retry loop, if
it fails to drop it logs an error, without aborting the current
feeding.

History

#2

Updated by Benjamin Dauvergne 3 months 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 3 months ago

  • Assignee set to Benjamin Dauvergne
#4

Updated by Benjamin Dauvergne 3 months ago

#6

Updated by Benjamin Dauvergne 3 months 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 3 months ago

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

Updated by Benjamin Dauvergne 3 months 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 3 months ago

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

Updated by Frédéric Péters 3 months 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.

#11

Updated by Benjamin Dauvergne about 1 month ago

Plus simple, ne pas s'occuper du deadlock juste faire les choses dans le bon ordre dans une transaction et ré-essayer.

#13

Updated by Benjamin Dauvergne about 1 month ago

  • Related to Bug #54808: pas de permissions pour SET deadlock_timeout added
#14

Updated by Benjamin Dauvergne about 1 month ago

Le 33 secondes c'est parce que les requêtes dans bijoe prennent au plus 30 secondes avant d'échouer (petite idée que wcs-olap devrait gagner un duel, mais je ne suis même pas sûr qu'un simple renommage de schéma prennent des verrous, par contre le schema drop en prend pleins, mais une fois le nom modifié il ne devrait plus y avoir d'accès de la part de bijoe).

#15

Updated by Benjamin Dauvergne about 1 month ago

  • Tracker changed from Development to Bug
#16

Updated by Benjamin Dauvergne about 1 month ago

J'ai récupéré atomic() depuis #56039 où il a disparu.

#17

Updated by Serghei Mihai about 1 month ago

Je valide une fois jenkins vert.

#18

Updated by Serghei Mihai about 1 month ago

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

Updated by Benjamin Dauvergne about 1 month ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 05c40317767e218acdb7675fec39ea2a34c7360b
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date:   Sat Aug 7 18:43:29 2021 +0200

    feeder: prevent situation of half-dropped schema (#54658)

    To prevent loosing currently loaded data wcs-olap, failing ro rename the
    temporary schema to its final name, wcs-olap will:

    - first, inside a transaction, rename the current schema instead of
      dropping it, then rename the new schema to the current schema's name;
      in case of failure it will retry 33 times sleeping 1 second between
      each attempt;

    - if successfull, drop the renamed old schema, again in a retry loop, if
      it fails to drop it logs an error, without aborting the current
      feeding.
#20

Updated by Frédéric Péters about 1 month ago

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

Also available in: Atom PDF