You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This ticket is inspired by an online discussion with @sbailey. The existing SQLite history QA DB should automatically protects against accidental writes during testing by the non-desi (datasystems) user at NERSC (KPNO). However, by experience SQLite's lock file mechanism can lead to unpredictable race conditions when the DB is accessed by multiple processes, potentially corrupting the database.
PostgreSQL is friendlier to multi-process access but needs to be configured to allow read/write access only to the desi (datasystems) user. It should be read-only for all other users.
The text was updated successfully, but these errors were encountered:
This ticket is inspired by an online discussion with @sbailey. The existing SQLite history QA DB should automatically protects against accidental writes during testing by the non-desi (datasystems) user at NERSC (KPNO). However, by experience SQLite's lock file mechanism can lead to unpredictable race conditions when the DB is accessed by multiple processes, potentially corrupting the database.
PostgreSQL is friendlier to multi-process access but needs to be configured to allow read/write access only to the desi (datasystems) user. It should be read-only for all other users.
The text was updated successfully, but these errors were encountered: