Mentre lavoravo su un container locale in cui ho importato dati da un forum SMF2 con oltre 20 anni di attività, mi sono imbattuto in un bug bloccante con Topic.reset_all_highest.
Dopo l’importazione dei dati, il mio database mostra circa 60.000 argomenti regolari e circa 400.000 argomenti di messaggi privati, e le query in Topic.reset_all_highest causano una sorta di crescita geometrica delle righe, con il risultato che il mio disco esaurisce lo spazio (con 120 GB liberi all’inizio).
Attualmente sto cercando di suddividere le query in blocchi gestibili ed eseguirle direttamente in Postgres, ma ovviamente è subottimale (e non sono sicuro che funzioni e produca risultati corretti).
Ho cercato di vedere se qualcun altro avesse avuto questo tipo di problema, ma non ho trovato nulla, quindi mi chiedo se questo possa essere in qualche modo correlato alla mia configurazione personale: sto usando l’ultima versione di Docker, per la cronaca.
Ho eseguito di recente un’importazione di dimensioni modeste che sembra bloccarsi indefinitamente su Topic.reset_all_highest e ho dovuto interrompere la query in Postgres per continuare. Non ho mai avuto questo problema prima e ho pensato che forse fosse solo che il mio server postgres era sovraccarico (ha un sacco di siti collegati).
Il mio prossimo passo è stato quello di spostarmi su un altro server postgres, ma non ci sono ancora arrivato.
Dopo che i primi due frammenti del mio esperimento “split query” sono andati a buon fine (X e Y per argomenti pubblici), ho provato con quello Z, e si è bloccato - cioè, la query era attiva secondo l’attività di postgres, e top mostrava il processo in esecuzione al 100%.
Così ho guardato di nuovo l’SQL e ho trovato il problema: entrambe le query terminano così
WHERE
topics.archetype <> 'private_message' AND
X.topic_id = topics.id AND
Y.topic_id = topics.id AND
(
topics.highest_staff_post_number <> X.highest_post_number OR
topics.highest_post_number <> Y.highest_post_number OR
topics.last_posted_at <> Y.last_posted_at OR
topics.posts_count <> Y.posts_count OR
topics.word_count <> Z.word_count
)
(l’altra ha ‘private_message’ come archetipo, ovviamente)
Il che significa che alla query manca
Z.topic_id = topics.id - il che causa l’intero aumento geometrico.
Modificare la clausola WHERE delle query in
WHERE
topics.archetype <> 'private_message' AND
X.topic_id = topics.id AND
Y.topic_id = topics.id AND
Z.topic_id = topics.id AND
(
topics.highest_staff_post_number <> X.highest_post_number OR
topics.highest_post_number <> Y.highest_post_number OR
topics.last_posted_at <> Y.last_posted_at OR
topics.posts_count <> Y.posts_count OR
topics.word_count <> Z.word_count
)
ha risolto il problema per me.
Dovrei aprire una PR?
Lo penserei. Se potessi trovare un commit che ha rotto quello, sarebbe ancora più convincente.
Ho aperto una PR per questo, con alcune sfortunata limitazioni (cioè, non riesco a immaginare come testare questa modifica).
Questa modifica sembra corretta, la unisco.
(Dal punto di vista dei test, dovrebbe esserci copertura e un test semplice sarebbe sufficiente per convalidarla, dobbiamo solo confermare che non ci siano regressioni)