PostgreSQL 10.2 repairs security and maintenance assumptions
Two security fixes in PostgreSQL 10.2 expose different trust boundaries, while its index fixes distinguish installing corrected code from repairing stored state.
An upgrade tool can handle a database correctly and still expose credentials through a temporary file. PostgreSQL 10.2 makes that distinction concrete. Its February 8 security update fixes a permissions error in pg_upgrade alongside a separate problem in partition-key processing. These failures deserve different explanations because their prerequisites and their affected boundaries differ.
The release announcement covers 10.2 and the corresponding supported-branch updates, 9.6.7, 9.5.11, 9.4.16 and 9.3.21. It also identifies corruption risks involving VACUUM and indexes. That combination makes this a maintenance release with consequences beyond replacing executables. Corrected software can prevent another occurrence while existing database objects still need attention.
I prefer PostgreSQL for relational work partly because its operational behavior is documented in enough detail to reason about. This release is a useful example. The interesting material is in the explanation of each failure and in the conditions attached to the upgrade instructions. A security identifier alone does not tell an operator which part of the installation needs examination.
A temporary file crosses an operating-system boundary
The 10.2 release notes explain that pg_upgrade's temporary output from pg_dumpall -g could inherit permissive access from the invoking user's umask. That output can contain database passwords. CVE-2018-1053 fixes the tool's failure to restrict this file, while the notes acknowledge that restrictive directory permissions or umask settings could already prevent exposure.
The mechanism matters because access to a temporary file is an operating-system permission question. Database authentication does not decide which local account can read a file in a shared directory. An account that lacks database privileges may still have filesystem access. A database administrator therefore has to consider the identity running an upgrade and the environment in which that identity creates files.
This does not establish that every previous upgrade disclosed a password. Exposure requires an access path to the file. A private working directory can prevent that path even when the file's own mode is too broad. Conversely, a workflow that depends on the administrator remembering a particular shell setting leaves part of the tool's security behavior outside the tool. Restricting the file directly removes that dependency for this temporary output.
The distinction also changes the meaning of remediation. Installing a fixed tool protects its subsequent execution. It cannot determine who may have read a file produced earlier under different permissions. That historical question depends on the actual environment. Treating the fix as prevention gives a precise claim, while treating it as evidence that no disclosure happened would claim more than the release establishes.
Partition expressions expose a different boundary
CVE-2018-1052 concerns partition keys containing multiple expressions. The release notes describe crashes and possible disclosure of backend memory with crafted input. Unlike the temporary-file issue, this failure occurs in server processing. The fact that both appear in one update should not make their access conditions interchangeable.
A memory disclosure is also different from an ordinary SQL error. An invalid statement should receive an error within the interface's defined behavior. Returning memory from outside the intended result violates a broader assumption about what a database connection can observe. The practical importance of the fix follows from that loss of control over information returned by the backend.
It is tempting to assess a partitioning bug solely by whether an application uses partitioned tables. Security review needs to examine the input an account can submit as well as the objects an application normally creates. The release's description of crafted input is the relevant warning. It does not justify inventing an exploitation procedure or asserting exposure for every account on every installation.
My judgement is that these two fixes belong in separate operational discussions. One concerns temporary credentials and local access. The other concerns server-side handling of partition expressions. Keeping those explanations separate helps an operator ask useful questions without implying that a filesystem restriction fixes a server memory error.
Correct binaries and existing indexes
The update announcement advises affected users to consider rebuilding GIN and hash indexes. Its upgrade instructions do not require a dump and reload for a minor update. It also calls out a changed cube operator whose dependent expression indexes and materialized views need rebuilding or refreshing. These exceptions make the scope of a maintenance operation explicit.
An index is stored state derived from table contents and indexing rules. Replacing the implementation of those rules does not, by itself, establish that every previously stored index entry agrees with them. This is why an instruction about rebuilding an object carries information that a package version cannot express. Both the new implementation and the object's existing contents matter to correctness.
The distinction is equally useful when reading incident reports. A system can truthfully report the fixed server version while retaining an object constructed before the fix. Version inventory answers which code is available to execute. It does not answer whether a particular derived structure has been reconstructed. Operational records need to retain that second fact when the release requires it.
This is also why a general recommendation to recreate every database would be a poor reading of the announcement. The project supplies narrower instructions tied to affected objects. Those instructions preserve the normal minor-update path while identifying the conditions that require additional work. Precision reduces unnecessary migration work and gives the exceptional steps a specific reason.
Reading a minor release as an operational change
The versioning note in the announcement confirms that 10.2 is a minor update to 10.0 or 10.1. That classification describes the release line and upgrade procedure. It does not imply that the bugs are unimportant or that every installation has identical follow-up work. The contents of the release determine those questions.
I value that separation because it makes a maintenance decision legible. The server version, the tool used for a major upgrade, and the state of affected indexes each provide different evidence. For this release, the immediate practical task is to install the corrected software and apply the documented object-specific steps where their prerequisites hold. The temporary-file fix then governs future pg_upgrade runs, while any assessment of earlier file exposure remains grounded in the permissions that actually applied.