Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19683: Can a stale postmaster.pid affect connections after
 PostgreSQL has already started successfully?
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: somya.sahu@brambles.com
Reply-To: somya.sahu@brambles.com, pgsql-bugs@lists.postgresql.org
Date: Thu, 10 Sep 2026 20:32:22 +0000
Message-ID: <19683-93cfb60259edbb9e@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19683-93cfb60259edbb9e%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19683
Logged by:          somya sahu
Email address:      somya.sahu@brambles.com
PostgreSQL version: 17.10
Operating system:   Windows
Description:       =20

Hi Team ,

We have followed below step to Migrate Postgres from C to D drive on windows
system using Veeam application .

Sequence of steps       Activity        Action By Team  Remarks
1       Change Raised   Backup Team
2       C & D Drive Snapshot Backup For US1514MS01      Windows Team    C
task Required
3       Veeam Configuration backup and Services stop    Backup Team
Backup Team Change
4       Veeam jobs and Repositories need to be stop     Backup Team
5       Uninstall PostgreSQL from C drive and related files     DB Team C
task Required (PostgreSQL Activity)
6       SQL DB Backup and move backup files to D drive  DB Team C task
Required (SQL DBA Activity)
7       Uninstallation of Veeam components from C drive and cleanup folders
Backup Team
8       Install PostgreSQL 17.10 on D drive of US1514MS01       DB Team C
task Required (PostgreSQL Activity)
9       Configure pg_hba.conf and hardcode approved IPv6 range  DB Team
10      Validate connectivity using localhost and hostname      DB Team
11      Install Veeam application in D drive and verify services/application
Backup Team     Backup Team Change
12      Migrate Veeam Backup configuration and point to PostgreSQL DB
Backup Team
13      Verify PostgreSQL database status and health Post Migration     DB
Team C task Required (PostgreSQL Activity)
14      Enable repositories from maintenance window in Veeam Applciation
Backup Team     Backup Team Change
15      Rescan inventory and backup infrastructure in Veeam     Backup Team
16      Run backup job sync with existing metadata      Backup Team
17      Enable backup jobs and run test job     Backup Team
18      Raise P1 vendor case if issues found during
migration/post-validation   Backup Team

The only instance where PostgreSQL was not shut down properly was during the
reboot that occurred as part of the TLS installation process.
Prior to that:
=E2=80=A2       PostgreSQL had been cleanly uninstalled from the C: drive.
=E2=80=A2       There were no active connections and no postmaster.pid file=
 present.
=E2=80=A2       PostgreSQL was successfully installed on the D: drive and b=
rought
online.
=E2=80=A2       The Veeam installation and migration completed successfully=
 and
required an active PostgreSQL connection, which indicates the database was
functioning correctly at that time.
This suggests the environment was healthy up to and including the migration.
The only improper shutdown occurred when the server was rebooted following
the TLS installation. After that reboot, PostgreSQL started successfully,
which indicates the old PID file had been cleared and a new postmaster.pid
file was created during startup.

After all this Now Application ( Veeam ) team is constant escalation stating
that its postmaster.pid file lock the connection . Here we need answer
/guidance

Note :- Below is DBA team understanding
"If the issue was solely related to the postmaster.pid file, we would expect
it to have been resolved once PostgreSQL successfully restarted after the
reboot.
However, Veeam remained non-functional until it was reinstalled.
Reinstalling Veeam would not typically affect PostgreSQL processes, remove,
or recreate the postmaster.pid file."

Since the Veeam reinstallation resolved the problem without any additional
changes to PostgreSQL,

We are trying to understand " Dose postmaster.pid block client connections
after successful PostgreSQL restart ?

Thanks,
somya.sahu@brambles.com