30.1. Memory Purge#
Usingmemory purge configuration parameters,Postgres Pro Standard can automatically replace data with zero bytes before it is deleted. This section describes how different types of data are handled. By default, all the memory purge parameters are switched on.
30.1.1. Deleting Files from External Memory#
When you run someSQL commands that delete files, the corresponding disk space is returned to the operating system. Such commands include: Commands that delete database objects: Commands that re-create objects: If thewipe_file_on_delete configuration parameter is switched on, the files to be deleted are first filled with zero bytes. TheDROP TABLEDROP TEMPORARY TABLEDROP MATERIALIZED VIEWDROP INDEXTRUNCATEDROP DATABASEDROP SCHEMAVACUUM FULLREINDEXALTER TABLE ADD COLUMN (with the default value)ALTER TABLE ALTER COLUMN TYPENote
ALTER TABLE DROP COLUMN command does not re-create the file. All the data contained in the deleted column remains inside the pages, although you cannot access this data usingSQL commands. To physically remove this data from the file, runVACUUM FULL after deleting the column.
30.1.2. Page Cleanup#
In accordance with the Multiversion Concurrency Control (MVCC) model, when rows are deleted (with the To ensure thatMVCC mechanism is working correctly,Postgres Pro keeps the deleted data in the page while the saved version of the row can be accessed by at least one active snapshot. If the row is referenced from indexes, index pages also keep references to the row versions that are deleted but not yet freed. When the row version is not referenced from any snapshot anymore, this version can be deleted with the To prevent access to the deleted row versions, make sure that thewipe_heaptuple_on_delete parameter is switched on in theDELETE command) the data stored in these rows is marked as deleted, but is not physically removed. In the case of row updates (with theUPDATE command), the old version of the row is deleted, and then a new version is inserted, so the previous value is not removed from the page either.VACUUM process. At the same time, all references to this row version are deleted from indexes. However, deleting does not mean physical removal: in normal operation, the corresponding space in the page is marked as free and can be used to store another row.postgresql.conf configuration file. In this case, theVACUUM process not only marks the page spaces as free, but also fills them with zero bytes.
30.1.3. Clearing Random-Access Memory#
While the server is running, random-access memory (RAM) is constantly allocated and released.Postgres Pro uses its own context-based system of memory allocation, in which memory is always allocated in one of the nested contexts. Deleting a context frees all the memory allocated in this context and the corresponding nested contexts. This approach helps to avoid memory leaks. Nevertheless, memory allocation and release are ultimately performed by the operating system. In normal operation, the released part ofRAM is returned to the operating system and can be allocated to another process. To remove all the data from the released part ofRAM, make sure that the following parameters are switched on in the wipe_memctx_on_free — this parameter fills the released memory with zero bytes if the released memory belongs to a context. wipe_mem_on_free — this parameter fills the released memory with zero bytes if the released memory does not belong to any context. AlthoughPostgres Pro always allocates memory within a particular context, you can still use this parameter to be on the safe side.postgresql.conf configuration file:
30.1.4. Cleaning up WAL Files#
Write-Ahead Log (WAL) is a standard method for ensuring data integrity, which enables database backups, point-in-time recovery, and data replication between servers.WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, that is, after log records describing the changes have been flushed to permanent storage. Thus,WAL can contain sensitive data that must be secured. Postgres Pro server always stores a certain number ofWAL segments in the To prevent unauthorized access to the releasedWAL segments, make sure that thewipe_xlog_on_free parameter is switched on in the For details onWAL configuration and usage, seeChapter 27.$PGDATA/pg_wal directory. The minimum amount ofWAL segments to store is defined by themin_wal_size parameter. In case of heavy load, the size ofWAL segments can increase up to themax_wal_size value, or even exceed this value a little. As long asWAL disk usage stays above themin_wal_size threshold, oldWAL segment files are deleted when they are released. Otherwise,WAL segments get overwritten.postgresql.conf configuration file. In this case, theWAL segment will be filled with zero bytes before it is deleted or overwritten.