Https://docs.sqlalchemy.org/en/20/errors.html#error-e3q8

Hello, everyone. Have you ever encountered the problem where the same tasks were submitted, and the database was frequently locked? Is this because I used “core.sqlite_dos” instead of “core.psql_dos”? And “core.psql_dos” is necessary for complex calculations? But it seems that this requires root privileges. May I ask which one you use for running complex calculations, “core.sqlite_dos” or “core.psql_dos”?

Hello,

Have you ever encountered the problem where the same tasks were submitted, and the database was frequently locked

Do you mean warnings of this form?

Failed to write global variable `{key}` to `{value}` because the database was locked. If the storage plugin being used is `core.sqlite_dos` this is to be expected and can be safely ignored.

Yes this is a limitation of sqlite and everyone experiences this. There is nothing we can do about it.

May I ask which one you use for running complex calculations, “core.sqlite_dos” or “core.psql_dos”?

There is nothing inherently stopping you from using sqlite (so core.sqlite_dos) for large number of calculations. It is just slower. It highly depends on your exact workflow if sqlite is enough or not, it is hard to really give you advice for your specific problem. As a rough guideline I would say up to ~1k jobs running in parallel can be handled by sqlite without much slow down (even though you already experience speed ups with psql at this regime). There is also the option to run aiida from your local computer where you can setup postgres (so using core.psql_dos), aiida can submit your calculations directly to a HPC, if you can authenticate via SSH key. Maybe you can tell us what or what kind of workflow you are planning to run so we can help you better.

Hi, yes. sqlite_dos is based on a SQLite database, that lives in a single file.
Very easy to manage (no database service to install and run), but has limited support of concurrent writes (only one python process at a time).

For any production run, we recommend indeed core.psql_dos.

See e.g. notes on the various versions in the 2x2 matrix here: Quick installation guide — AiiDA 2.7.3 documentation

Note that it’s possible to install PostgreSQL as root, but if you use conda, you can install PostgreSQL without root permissions (you only need to start it again e.g. if you reboot your machine, while when it’s installed as a service, restarting at reboot is typically automated).

Note for us: We should probably also add a note on using psql_dos here (and make this section visible one level up in the TOC (so it shows on the left bar): How to manage your installation — AiiDA 2.7.3 documentation

Just because it helps also us clarify in the docs the limitations of the sqlite_dos version (and possibly see if some limitations can be removed):

can you please describe exactly your use case?

E.g.: are you submitting many things in a for loop in bash, with a python script submitting one job at a time? Or are you doing the loop in python, so effectively running only 1 python process? (I guess the first?)

Actually, I think I see that you are running the daemon. Indeed, this cannot be done with SQLite (again, note for us: we should probably stop verdi deamon start and similar commands when using the SQLite DB, for now?)

If you are on an appropriate Linux flavour and have access to Podman, it is also possible to run Postgres “declaratively” as a container without root permissions. It’s not an appropriate thing to do on large shared HPC, but a nice way to work in a smaller shared server, cloud VM etc.

I have been doing this recently using “quadlet”:

  • put a file like this at ~/.config/containers/systemd/postgres.container
[Unit]
Description=PostgreSQL (For AiiDA)

[Container]
Image=docker.io/library/postgres

# Use volume defined below
# PROBABLY NEED TO DO THIS PROPERLY!
Volume=postgres.volume:/var/lib/postgresql/data

ContainerName=some-postgres
PublishPort=5432:5432
Environment=POSTGRES_PASSWORD=<some-password-string>
Environment=PGDATA=/var/lib/postgresql/data/pgdata

# Default "split" doesn't seem to play nicely with --user
# # Use this for Podman 5
# CgroupsMode=enabled
# # Or this for Podman 4 (i.e. rocky 8)
PodmanArgs=--cgroups=enabled

[Service]
# Restart service when sleep finishes
Restart=always
# Extend Timeout to allow time to pull the image
TimeoutStartSec=900

[Install]
# Start by default on boot
WantedBy=multi-user.target default.target
  • and a file like this as ~/.config/containers/systemd/postgres.volume
[Volume]
User=<my-username>
Group=<my-group>
  • Pick up the changes with
systemctl --user daemon-reload
  • then start the service with
systemctl --user start postgres

Note that this is a systemd service, with the restart magic and text configuration that implies, but with the --user flag you never need elevated permissions. The key stuff happened when podman was installed!

I just ran the ‘PwRelaxWorkChain’ using a conventional cell, ‘✘ storage: Unable to instatiate profile’s storage. Error: OperationalError: (sqlite3.OperationalError) database is locked [SQL: PRAGMA main.table_info(“alembic_version”)] (Background on this error at: Error Messages — SQLAlchemy 2.0 Documentation) occurred again. However, I ran the same workflow just using a primitive cell before, and it ran normally. Besides, even the ‘IRamanSpectraWorkChain‘ can be successfully done. So, I don’t know why it is often locked and when. In addition, I try to 'verdi storage migrate’ before, the DB can return to normal. But now it failed. I don’t know how to solve this problem now. What do you suggest I do? Thank you very much for your reading. I will be very grateful.