Curse! O_O

This is not supposed to happen.

Regenerating the table right now.

There is a "monuments_all_tmp" table, btw.

In T111252#1599392, @JeanFred wrote:

Curse! O_O

This is not supposed to happen.

Regenerating the table right now.

Script succeeded. Should be back now. Can someone confirm?

In T111252#1599453, @Emijrp wrote:

There is a "monuments_all_tmp" table, btw.

Yes, that’s how fill_table_monuments_all.sql proceeds : merging all data in monuments_all_tmp, dropping monuments_all, renaming monuments_all_tmp to monuments_all. So something went wrong after dropping but before renaming, which is odd.

There is something wrong in monuments_all again. SQL queries are sloooow and don't finish. In _tmp are OK.

In T111252#1601922, @Emijrp wrote:

There is something wrong in monuments_all again. SQL queries are sloooow and don't finish. In _tmp are OK.

Yeah, I was noticing that too. I think it is because the categorisation job and the update table job were running at the same time. I killed the former and the latter finishes. How is it on your end @Emijrp?

Can you please update the database only handly?

I don't think that Wikipedia lists change a lot, so we don't get much updating it (daily?) with cron.

I think that it is better to have "old" data in the map, that break the database and have a map without a monument.

In T111252#1601925, @Emijrp wrote:

Can you please update the database only handly?

I don't think that Wikipedia lists change a lot, so we don't get much updating it (daily?) with cron.

I think that it is better to have "old" data in the map, that break the database and have a map without a monument.

It’s actually the other way around. In both incidents, I had started a manual update (following hot config changes) that turned out to be clashing with the long-running job − so, yeah, completely my fault, but obviously I won’t be doing that again.