SQL errors in log file

[Hk1020]

Versions

• Pi-hole:
• AdminLTE:
• FTL:
• Core v6.0.5FTL v6.0.4Web interface v6.0.2

Platform

• OS and version:

• Platform:

Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

Expected behavior

A clear and concise description of what you expected to happen.

Actual behavior / bug

Since update to v6 I see several SQL errors in ftl.log like the below and since about today pihole a lot of ads occur. Before there were essentially no ads anywhere.

2025-03-17 15:10:04.190 ERROR domain_in_list("browser.events.data.trafficmanager.net", 0x7f97ff0008, antigravity): Failed to perform step: SQL logic error
2025-03-17 15:10:04.190 ERROR SQLite3: no such table: main.gravity in "SELECT adlist_id from vw_gravity WHERE domain = ? AND group_id IN (0);" (1)
2025-03-17 15:10:04.190 ERROR domain_in_list("browser.events.data.trafficmanager.net", 0x7f97f2f668, gravity): Failed to perform step: SQL logic error
2025-03-17 15:10:04.191 ERROR SQLite3: no such table: main.antigravity in "SELECT adlist_id from vw_antigravity WHERE domain = ? AND group_id IN (0);" (1)

A clear and concise description of what the bug is.

Steps to reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Debug Token

• URL:

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

[yubiuser]

Try

systemctl stop pihole-FTL 
sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL.db.bck
systemctl start pihole-FTL

[Hk1020]

Try

systemctl stop pihole-FTL 
sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL.db.bck
systemctl start pihole-FTL

Thanks, that solved it. The old .db file had swollen to 615Mb. I guess I can delete it? Will this file or anything else in /etc/pihole grow indefinitely?

[yubiuser]

This file contains your long-term history. By default it saves the last 91days. Old database entries will be overwritten by new ones, but the file size will never decrease automatically. If you have the same amount of queries over a 91 day period it will stop growing at some point

[Hk1020]

So it will grow with time unless you always do the same things. Is there any disadvantage - except of a short interruption - of regularly deleting it with what you showed above?

[yubiuser]

You loose the long term history and the stats in the network overview. Otherwise it's fine. You could also decrease the retention duration or manually VACUUM the database to reduce the file size.

[Hk1020]

Thanks. By trying the vaccum on the old backup it turned out that the file was actually broken.