Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vlYoK-000jNY-0Q for pgsql-general@arkaria.postgresql.org; Thu, 29 Jan 2026 20:40:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vlYoI-000srj-0T for pgsql-general@arkaria.postgresql.org; Thu, 29 Jan 2026 20:40:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vlYoH-000srb-0X for pgsql-general@lists.postgresql.org; Thu, 29 Jan 2026 20:40:14 +0000 Received: from fhigh-a3-smtp.messagingengine.com ([103.168.172.154]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vlYoE-000000004cz-1zwV for pgsql-general@lists.postgresql.org; Thu, 29 Jan 2026 20:40:13 +0000 Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id 22F46140018D; Thu, 29 Jan 2026 15:40:08 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Thu, 29 Jan 2026 15:40:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1769719208; x=1769805608; bh=BDz1remAl8GjtQr5cVMNNIt/mdjPTbAnLCc/67HDeGU=; b= TbtOqWhgzbq2SGnieneJecsP5UPe01sUTJDl3TKRcQRfuFqR1SabI0rybl5OOQ7D I2DqHe4Pka1bMt+WmwYXUcrtx4L7syhxnlDLPS9sfox1hF3npSKYnlK3GJo+ARcC HkGJW0AkWQ1jP5AgaqvPZ9m0AVUpRi7FGc6qIX1ocUAYXTG1w/+25KXoN0z7P4Am 4C9OKAqk33HfZ9X+rH7SAyyWR/aqRXGeZxYlZ8Zj0PGmKELwXysxHO6yvzsGPuqx EYdY6hMm0HebLuVlM4r3TmByfk48/zoSQJqp47+LU8nrATFkNjfqJso53DZdWzrV vJxDsyEy4y+YICWBeXXnfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1769719208; x=1769805608; bh=B Dz1remAl8GjtQr5cVMNNIt/mdjPTbAnLCc/67HDeGU=; b=eBEEmK5jIRcw9vq1e R4o+zERJ3enLDukDf4U5vx5qWOOpGel7TRUQjM+1XYhUb0Y//EoRhs9qWsBk6/jF 9qZJYC3GLSUEjlmA0jfWLxNia+0HSRojVgxIiD9q607YjdztsWTSL2p/uzbrzSmS HkrHLc+XroW1E720Ilt43//TDJ8jpJR5/Aflo80uMQasvmnRmAQI7tc1KqRSuauN YWKIUeTHZUp7Yf7rduvNlKj+4cW+LDIsoRc+GjWrcd5wGQ2/Rvp4NDi2q0o2kIJy Uh594fY4u7W/vy+lAU4ZviP8cjml+b30yJvjS+XBcmgECxmCesMJ1qTAD1FkHvgF JPNNA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduieejudekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertd dtvdejnecuhfhrohhmpeetughrihgrnhcumfhlrghvvghruceorggurhhirghnrdhklhgr vhgvrhesrghklhgrvhgvrhdrtghomheqnecuggftrfgrthhtvghrnhepvdeitdeugfelte ffteetteetudeiheeigfejffejfefhgeefjeeivedutdejtdeunecuffhomhgrihhnpehg ihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhmpdhnsggp rhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehsthgvvhgvjh esshhtvghvvghjrdhnrghmvgdprhgtphhtthhopehpghhsqhhlqdhgvghnvghrrghlsehl ihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Jan 2026 15:40:07 -0500 (EST) Message-ID: Date: Thu, 29 Jan 2026 12:40:06 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: What happens if the socket lock file is deleted? To: "stevej@stevej.name" , pgsql-general@lists.postgresql.org References: Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 1/29/26 12:29, stevej@stevej.name wrote: > In software I have developed separately, I have noticed that most systems will periodically delete files within the temporary directory hierarchy that have not been accessed recently, and that includes lock files for long running processes. I have never noticed the lock file associated with a postgreSQL socket be missing though. > > Does PostgreSQL periodically touch the lock file so it won’t be deleted? Alternatively, does PostgreSQL simply re-create the lock file if it has been deleted? I know the documentation says to never “manually”’delete one of those lock files. > From here at ~line 1781: https://github.com/postgres/postgres/blob/master/src/backend/postmaster/postmaster.c /* * Once a minute, verify that postmaster.pid hasn't been removed or * overwritten. If it has, we force a shutdown. This avoids having * postmasters and child processes hanging around after their database * is gone, and maybe causing problems if a new database cluster is * created in the same place. It also provides some protection * against a DBA foolishly removing postmaster.pid and manually * starting a new postmaster. Data corruption is likely to ensue from * that anyway, but we can minimize the damage by aborting ASAP. */ if (now - last_lockfile_recheck_time >= 1 * SECS_PER_MINUTE) { if (!RecheckDataDirLockFile()) { ereport(LOG, (errmsg("performing immediate shutdown because data directory lock file is invalid"))); kill(MyProcPid, SIGQUIT); } last_lockfile_recheck_time = now; } -- Adrian Klaver adrian.klaver@aklaver.com