Clean Up Polyspace Access Database

To optimize the performance of the Polyspace^® Access™ database, perform regular database clean up operations such as the deletion of old or obsolete projects and database vacuuming. It is recommended that you back up your database before you perform a clean up operation. See Create Database Backup.

Delete Project Runs or Entire Projects

When you delete a project from the Project Explorer of the Polyspace Access web interface by clicking Delete project from the right-click menu, or at the command line by using the polyspace-access -delete-project command, Polyspace moves the project to the ProjectsWaitingForDeletion folder. The project, including all the runs that you uploaded to that project, remains in the database until you explicitly delete the project. See Delete Projects from Database.

The ProjectsWaitingForDeletion folder is visible only to Polyspace Access users with the role of Administrator.

To help manage the size of your database, define a policy for how often you delete older project runs from the database. You can define a deletion policy per project and specify how frequently Polyspace deletes older runs based on:

The age of a project run — Specify a maximum number of days (MAX_DAYS) to keep runs in a project. If the number of days since a run was uploaded exceeds the value of MAX_DAYS, Polyspace deletes the run from the database.
The number of runs in a project — Specify the maximum number of runs (MAX_RUNS) to keep in a project. If a project already contains MAX_RUNS number of runs and you upload a new run, Polyspace deletes the oldest run in the project from the database.

Polyspace applies the deletion policy only when you upload a new run to the project. If the age of a project run olderThanMaxDays exceeds the value of MAX_DAYS but you do not upload a new run to that project, Polyspace does not delete the run olderThanMaxDays.

You can set a deletion policy only if you have a Polyspace Access role of Administrator or Owner.

Caution

You cannot recover the data that you delete from the database unless you have a backup copy of the data.

Manage Deletion Policy From User Interface

To set, unset, or manage a deletion policy from the Polyspace Access interface, select a project in the Project Explorer and click the Deletion Policy link in the Project Details pane.

Deletion Policy link highlighted in the Project Explorer to open the Runs Deletion interface

In the Runs Deletion window, you can:

Select Custom to set a deletion policy or None to unset the policy.
Manage the deletion policy by specifying the maximum number of days and maximum number of runs that Polyspace uses as thresholds for project runs deletions. You can specify one or both thresholds.
When you specify both thresholds, Polyspace deletes a project run if that run meets either threshold.
Select individual project runs to delete manually. After you select the runs, click to delete the selected runs from the database.
Set a run as persistent to exclude it from the deletion policy. Use this property to protect runs of interest from deletion. For instance, you might want to keep the first run that you upload to a project as a baseline, but still apply a deletion policy to all other runs that you upload to that project. Polyspace does not count runs that you set as persistent when applying the maximum number of runs deletion policy.
To set a run as persistent, double-click the cell in the Persistent column that corresponds to that run, and select Yes. You can also set a run as persistent at the command line when you upload the run. See Manage Deletion Policy at Command Line.
When you exclude a run from the deletion policy, the run remains in the database until you explicitly delete it. Unset the persistent property before you select the run for manual deletion.

The deletion policy automates the deletion of only project runs from the database. To delete a project and all its runs from the database, see Delete Projects from Database.

Manage Deletion Policy at Command Line

To manage a deletion policy at the command line, use the polyspace-access binary with these commands.

Command	Action
`-get-deletion-policy projectPath`	View the current deletion policy of the project with the project path `projectPath`. For example, to view the deletion policy of the project `public/example_BF`, use this command: polyspace-access -get-delete-policy public/example_BF -host ... Connecting to https://example-access-server:9443 Connecting as jsmith Current deletion policy: MAX_RUNS 10 Command Completed
`-set-deletion-policy projectPath` `-max-runs MAX_RUNS -max-days MAX_DAYS`	Set or edit the deletion policy of the project with the project path `projectPath`. You can configure the deletion policy to use the age of a project run, the number of runs in a project, or both the age and number of runs as thresholds for project run deletions. When you specify both thresholds, Polyspace deletes a project run if that run meets either threshold. When you set a deletion policy, Polyspace applies the policy on each subsequent upload. If you do not upload additional runs to the project, Polyspace does not delete any runs, even if those runs meet the policy criteria for deletion. For example, to set a policy where Polyspace deletes all runs older than 30 days from the project `public/example_BF`, use this command: polyspace-access -set-delete-policy public/example_BF -max-days 30 -host ... Connecting to https://example-access-server:9443 Connecting as jsmith Current deletion policy: MAX_RUNS 10 New deletion policy: MAX_DAYS 30 Command Completed The command overwrites an existing deletion policy. For instance, if a project has a deletion policy to allow only 10 runs per project (`MAX_RUNS`), and you apply the preceding command to that project, you overwrite the `MAX_RUNS` condition and Polyspace uses only the `MAX_DAYS` condition.
`-unset-deletion-policy projectPath`	Unset the current deletion policy of the project with the project path `projectPath`. For example, to unset the deletion policy for the project `public/example_BF`, use this command: polyspace-access -unset-delete-policy public/example_BF -host ... Connecting to https://example-access-server:9443 Connecting as jsmith Current deletion policy: MAX_DAYS 30 New deletion policy: NONE Command Completed
`-upload resultPath -exclude-from-deletion`	Exclude an upload from the deletion policy. Use this option to protect project runs of interest from deletion. For instance, you might want to keep the first run that you upload to a project as a baseline, but still apply a deletion policy to all other runs that you upload to that project. Polyspace does not count runs that you exclude from deletion when applying the maximum number of runs deletion policy. When you exclude a run from the deletion policy, the run remains in the database until you explicitly delete it. The run appears as Persistent in the Runs Deletion window on the Polyspace Access interface. You cannot delete individual runs manually at the command line.

The deletion policy automates the deletion of only project runs. To delete a project and all its runs from the database, Delete Projects from Database

Delete Projects from Database

If you are a Polyspace Access user with a role of Owner or Administrator, you can delete a project without removing it permanently from the database.

In the user interface, right-click the project in the Project explorer and select Delete Project.
At the command line, use the -delete-project or the -move-project commands to move that project to the ProjectsWaitingForDeletion folder.

Polyspace moves the project and all its runs to the ProjectsWaitingForDeletion folder, which is visible only to Polyspace Access users with the role of Administrator.

To delete a project and all its runs permanently from the database:

In the user interface, right-click the project in the ProjectsWaitingForDeletion folder and select Empty Folder.

At the command line, use the polyspace-access -delete-project command and specify a project in ProjectsWaitingForDeletion folder.

For instance, this command deletes the project myProj from the database.

polyspace-access -delete-project ProjectsWaitingForDeletion/myProj -host example-access-server:9443
login: jsmith
password:
Connecting to https://example-access-server:9443
Connecting as jsmith
Deletion requested for project "ProjectsWaitingForDeletion/example_project"
PROJECT_DELETED ProjectsWaitingForDeletion/example_project
Command Completed

You can perform this action only if you have a Polyspace Access user role of Administrator.

Restore Deleted Projects

A Polyspace Access user with the role of Administrator can restore deleted projects that are in the ProjectsWaitingForDeletion folder by moving to another folder in the Project Explorer or by using the polyspace-access -move-project command.

You cannot restore projects that are deleted from the database unless you have a backup copy of the database.

Transfer PSCAUTO Scripts to Deletion Policies

If you use PSCAUTO scripts to manage your database clean up, and you update to Polyspace Access R2023b or later, Polyspace transfers the scripts that were assigned to specific project to deletion policies for those same projects.

For example, consider this PSCAUTO script that is assigned to the project public/Bug_Finder_Example (Bug Finder) and which sets the maximum number of runs in the project to 10 runs:

assign_to_project "public/Bug_Finder_Example (Bug Finder)" AFTER_STATISTICS myScript
clean_project "public/Bug_Finder_Example (Bug Finder)" MAXRUNS 10

After you upgrade your version of Polyspace Access, when you view the deletion policy for the project public/Bug_Finder_Example (Bug Finder) in the Polyspace Access user interface or by using the command

polyspace-access
                        -get-deletion-policy

, you see that the deletion policy for the project matches the command in the script (MAX_RUNS=10).

Polyspace does not transfer PSCAUTO script that do not use the assign_to_project command. These are typically scripts that you ran once instead of every time you uploaded results to Polyspace Access.

You cannot use PSCAUTO scripts to manage your database clean up in R2023b or later versions of Polyspace Access.

Perform Database Vacuuming

When you run a command to update or delete a row in a database table, the command does not remove the row from the table because other database transactions might still use the old version of the row. To reclaim the disk space of old rows that are no longer used by any database transaction, use the PostgreSQL vacuumdb command. Vacuuming the database regularly prevents your database disk space from growing too large or fragmented.

Before you perform a vacuum operation, ensure that no users are connected to Polyspace Access, then stop the Polyspace Access web server and ETL services. To stop the services, from a terminal on the server hosting these services, use this command and enter:

docker stop polyspace-access-etl-0-main polyspace-access-web-server-0-main

Note

If you run Polyspace Access version R2021b or earlier, the docker container names might be different. To view the names of currently running containers, use the command docker ps --format '{{.Names}}'.

To perform a regular vacuum on your Polyspace Access database, open a terminal on the server hosting your database and enter:

docker exec polyspace-access-db-0-main vacuumdb -U postgres prs_data

You can also run the vacuumdb command and use the --analyze option to update the PostgreSQL server statistics. Accurate server statistics help prevent degradations in the performance of the database. Open a terminal on the server hosting your database and enter:

docker exec polyspace-access-db-0-main vacuumdb -U postgres --analyze prs_data

To minimize the size of your database tables and return unused space to the operating system, perform a full vacuum by running vacuumdb using the --full option. Open a terminal on the server hosting your database and enter:

docker exec polyspace-access-db-0-main vacuumdb -U postgres --full prs_data

This operation can take a long time and writes a new version of the table that does not have any empty spaces. When you perform a full vacuum, no other database process can run in parallel. The database is not accessible during a full vacuum.

Establish a policy for how often you want to perform a regular and a full vacuum. For instance, perform a regular vacuum weekly.

After you complete the vacuum operation, restart the Polyspace Access web server and ETL services. Use this command:

docker start polyspace-access-etl-0-main polyspace-access-web-server-0-main

After you restart the web server service, you might have to wait a few moments before you can open Polyspace Access in your web browser.