On 5/11/24 11:32, Phil Stracchino wrote:
On 5/10/24 18:31, Phil Stracchino wrote:
On 5/10/24 14:33, Phil Stracchino wrote:
On 5/9/24 21:07, Marcin Haba wrote:
Runscript {
Runs When = After
Runs On Client = no
Console = ".bvfs_update jobid = %i"
}
Yeah, this is consis
On 5/13/24 14:20, Phil Stracchino wrote:
If I were to try to *fix* this compatibility issue (and it would quite
possibly perform better this way anyway), what I would do there is add a
LIMIT 10 and then loop on it until ROW_COUNT() < 10. BEST
PRACTICE for Galera performance is to try to
Differential backup completed, bvfs-update is running now ...
The DELETE FROM PathVisibility query is VERY, VERY slow, but bulk
deletes in MySQL have always been slow.
There is a technique that optimizes bulk delete speeds, but it adds
significant complexity. It goes basically like this:
On 5/13/24 15:25, Phil Stracchino wrote:
hmm. evidently I got something wrong in my loop there.
--
Phil Stracchino
Fenian House Publishing
ph...@caerllewys.net
p...@co.ordinate.org
Landline: +1.603.293.8485
Mobile: +1.603.998.6958
___
On 5/13/24 18:38, Phil Stracchino wrote:
On 5/13/24 15:25, Phil Stracchino wrote:
hmm. evidently I got something wrong in my loop there.
DOH Single-character typo...
--
Phil Stracchino
Fenian House Publishing
ph...@caerllewys.net
p...@co.ordinate.org
Landline: +1.603.293.84
Fixed now.
This is the CORRECTED patch to bvfs.c to make .bvfs_update stay under
the 128K-row transaction limit for Galera 3.
--- bacula-15.0.2/src/cats/bvfs.c.orig 2024-03-22 05:48:41.0 -0400
+++ bacula-15.0.2/src/cats/bvfs.c 2024-05-13 18:44:03.553492388 -0400
@@ -723,10 +72
