Dennis Felsing
Dennis Felsing
I have tried switching to `gi-cairo` instead of svgcairo. Now I'm running into the next problem: ``` Failed to build hashtables-1.3.1. Build log ( /home/deen/.cabal/logs/ghc-9.0.2/hashtables-1.3.1-b18534b8e35d69179499dfbf94fca581c20ec0d1aec725813e429075202373a7.log ): Configuring library for hashtables-1.3.1.....
``` Failed to build haskell-gi-0.26.2. The failure occurred during the configure step. Build log ( /home/deen/.cabal/logs/ghc-9.0.2/haskell-gi-0.26.2-536188c901579b27a3ccfb812769db11726ed1d9d0076d1cae7e9cdf0e0f1a1f.log ): [1 of 1] Compiling Main ( /home/deen/git/ghc-vis/dist-newstyle/tmp/src-1938273/haskell-gi-0.26.2/dist/setup/setup.hs, /home/deen/git/ghc-vis/dist-newstyle/tmp/src-1938273/haskell-gi-0.26.2/dist/setup/Main.o ) Linking /home/deen/git/ghc-vis/dist-newstyle/tmp/src-1938273/haskell-gi-0.26.2/dist/setup/setup ... Configuring...
There might be a connection to https://github.com/yugabyte/yugabyte-db/issues/10716 which happened immediately after this bug. On the third attempt other commands like `create type` are just timing out, so something clearly broke...
As discussed on call I will try with dropping database after each run to ensure we don't run into OoM
Similar failure now with only one database (12 tables currently) after 3 hours: ``` Reproduce with: git checkout da0be044-dirty && ./long_system_test.py --scenario=backup_restore --portal=portal-iam.dev.yugabyte.com --universe_uuid=76e945a0-0084-4d71-be95-5e0896cdfccd --threads=10 --runtime=5 --complexity=full --drop --seed=216376 ```...
Happened again on the same universe, so this is blocking further B&R testing with LST.
Is it possible some of the last values are not flushed yet and thus don't get backed up properly? Flushing them manually to check if that fixes it could work...
Seen on 2.12.9.1-b1 as well with a hard inserting workload: ``` [centos@hostname ~]$ sudo cat /home/yugabyte/tserver/logs/yb-tserver.FATAL.details.2022-08-11T17_58_29.pid7951.txt F20220811 17:58:29 ../../src/yb/tablet/mvcc.cc:392] T 29dc41ef1bbf459596b10f9505814bbc P bcfadf5152d547afa34bf5efce83971f: T 29dc41ef1bbf459596b10f9505814bbc P bcfadf5152d547afa34bf5efce83971f: Recent 32 MVCC...
Doesn't happen with `enable_lease_revocation=false` gflag.
It required very high load and a few hours of running, I'm not sure how well it reproduces. Should I try on 2.8?