Workaround to removing a watchtower with postgres backend

[GordianLN]

Background

Cannot remove watchtower (duh). One of several and known different errors (latest is I cannot do it while session is being negotiated).
Have postgres backend, and not be able to recur to the usual workaround of stop all services > delete wt.db > restart all services, as I do not have a wt.db file (duh II).
Restart lnd with wtclient.active=false in lnd.conf out of desperation.

Your environment

• version of lnd 0.15
• which operating system (uname -a on *Nix) raspios bullseye
• version of btcd, bitcoind, or other backend .22
• any other relevant environment details //

Steps to reproduce

Decide to remove watchtower as that is the last viable suspect for all issues of slow lnd start and high latency during rebalances. Notice you cannot do it.
Restart lnd with wtclient.active=false in lnd.conf out of desperation.

Expected behaviour

Being able to remove watchtower normally, but let's not be hasty. Being able to enact a workaround like boltdb operators can would be fine for now.

Actual behaviour

What's explained above.

I would like to get an official statement that will confirm, or not, that deleting the whole watchtower postgres table while all services are stopped, is a good working solution exactly like deleting boltdb file.

[lucasdcf]

I converted this into a discussion as the actual issue is #4420

Let me confirm if deleting the watchtower Postgres table will have the same effect as deleting the wt.db file and if it’s ok to do it as a workaround. I’ll get back to you asap.

[GordianLN]

Hi, are there news about this? What's the official stance for postgres, can you force-remove a watchtower by deleting the table in database?

[lucasdcf]

towerclientdb_kv
towerserverdb_kv

These are the two tables you'd need to delete. Theoretically, it should have the same effect as deleting wt.db, and it should be safe, but we'd prefer to test it first before actually recommending it, just to make sure.

[GordianLN]

well, those are the tables that I was expecting already to have to delete, I'd rather say only towerclientdb_kv as towerserver is working for another client.
I'd love to get an official statement as of the safety of this method, before I go and wreak havoc by doing undocumented stuff.

[GordianLN]

So? I'm kinda still waiting for an official reply on this matter :-)

[guggero]

I'm not sure what exactly you expect in terms of "official" answer. Lucas did forward the response from our internal chat, so that's pretty much what you'll get.
I can perhaps add that currently we more or less map what previously was a single .db file onto a SQL table. So deleting towerserver_kv should have the same effect as deleting the watchtower.db file. But we also wouldn't "officially" recommend deleting bolt DB files. You can take a look at the mapping for the different databases here.

We need to fix some of the issues around watchtowers, I agree. And that is a priority for 0.16.

[GordianLN]

Thank you. What left me hanging, and not feeling alright in just deleting the table, is the "we'd prefer to test it first before actually recommending it, just to make sure", and then no test results were posted after a few weeks 😅

[GordianLN]

Or to try and explain better, I would like to know if deleting the wt client table would have the same exact effect of deleting the wt client db file, which is a procedure amply tested by plebs until now with no catastrophic results ever being reported. I seem to understand the answer to this is yes, and this also seems to be confirmed by reading the code you linked to with the non-existing level of my knowledge of go.

My issue doesn't seem to stand for the WT server, so I don't think I need to delete that table, just the wt client is gone bonkers.