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 1wgrTb-006Sdu-1Z for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Jul 2026 22:07:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wgrTa-003IHG-0x for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Jul 2026 22:07:42 +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 1wgrTa-003IH7-00 for pgsql-hackers@lists.postgresql.org; Mon, 06 Jul 2026 22:07:42 +0000 Received: from mail-yw1-x112a.google.com ([2607:f8b0:4864:20::112a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wgrTX-000000028Af-0q5T for pgsql-hackers@lists.postgresql.org; Mon, 06 Jul 2026 22:07:41 +0000 Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-7ff05e5d009so40577737b3.1 for ; Mon, 06 Jul 2026 15:07:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783375657; cv=none; d=google.com; s=arc-20260327; b=RMCl6B0chFNnYv+6V+r/RGa4mpdaqtISAaMdHU+gH9IKl1zY7z6XjNbj0bXkVpmZ3h bqKJe3EXyXg2OmZRHFs5Rn8ZNDtA7Ptqx/oCn3W3k0FJWJLjsBi24VO+NWLCamehBc6J o5EO2aUJaluhxkeX/lbNlfm8MqWa6kqyqPbB7Wdji5Qzv6UYGe4S2XulIsYJXyluu/dy v01qfod7XGqbCkq5agedC+7PkNXcpm6NLH6mqjxMTcWh4oiJ6mvtaXXTj7yQhkuRTRKA rsilhHJv7YGUbCcQvhQYYMH0MifeIkJAzLBXo4/9xZBQfPgNTEOc7FnNFu9R0Bmkdj6N y3OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :dkim-signature; bh=vGzyq9jAQhVsq1AsW1kM6/8mXHSHPctlX3jNRZSQ6Qo=; fh=nwNxTtLLPTU0ewfLM7SSbrjMajMl+wwnFkCY/fi90vE=; b=q4yimo+eFSAR+qQJvOP537/TmcndSQoL6FJWYm9AjcdQKyZVZI+q7DZMNROPvLghSw x6mNeWtmcLn5HK2rmCWE206GSt1YSpqBVzbEzfJQ3uskKO10IwML5RYr/QQmY6MZU2Us ZE6dFe4soRtq7kNyefExwH6qWFekfJmPnLF6v81Rsyedq8VOaAjZ903tjKXNsfjyp+d/ +Y8c/DdRqnLDJ0EQPJ4OM1WwH13xhgyU+gP8euz2EpH6+lkaAlF7/OQrcm3wcD+P+e1f blDpWbC4dYKQD6LPYa8OSpzZSEE4zHwGaM5xp3L8cN3nLlPL+gew4RPftNjw8TfTTCUZ 1j2g==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=percona.com; s=google; t=1783375657; x=1783980457; darn=lists.postgresql.org; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :from:to:cc:subject:date:message-id:reply-to; bh=vGzyq9jAQhVsq1AsW1kM6/8mXHSHPctlX3jNRZSQ6Qo=; b=k28PrRTuEmRBBXNJpuhtYTfhiXEFyPwWm9nVBwt/ws0eym4Y7281ZMrlg1Buiym4uR ZqeKTJGtVS0yKDU6h7IZVk1WAA03WJceTlRvrpuSofqQbM5zfdR44IEiOQnPgmriuKbT JHcywe1gVxZIJXhhJkXTA2ReB6sywWX3gMLe8D06wLBL3V0szcshUft+GzVJSeCYObm6 F3hPBLnchSEqZ/7DU45Onu1OPrmyxcVKOvXf4fQ1x/kCecRoerBoMNBsPcxr25F86S1+ nj5FEqzqsxbxXND24VcCcmm+WDdWHVDxRpUnu9OeKgPT0f/IzTru2yyyNpB4QKa7r0ZN vcYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783375657; x=1783980457; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vGzyq9jAQhVsq1AsW1kM6/8mXHSHPctlX3jNRZSQ6Qo=; b=FW8dzyFoN/9KIKk3conKTPP8ExED+fx1lm6UKKzHrbJ8frjXw6/uWR5P1GtsEjuwLR 5Y9vLXnHWUiJtiK+Vjicw72evxC77RjzRunQoHTQ6GNTsWCpJ5PygiTQcUogcer6+Mij Hz9WGBGy4+AWu0uiATyg4KD1bnwXR6QcKcwtM+r75m4u5QQBTFILUtgcWBN0dFW0Ya7o FbScSJ5HRKOwZSCum3ZfqRZ7H+rLHFAomSju1SP87R1sNFj5SyFP89uwHs/Ta2qe88KH c0MzXzrDmF25Ioa3SEos/QqFzlYALkyfO6BFlHiEumxInfvXUMxZ9nSu8tqCa4BpJ5XP BsOg== X-Gm-Message-State: AOJu0Yw6XyXxkPeUGK1qyqjLFuujRU7rLZojomBuo//NJLJSWeF9gwFd DfZOLcRYZq061bnoB4XVS9gULuIWIiZziIMkP7kLTn0z8QbRPFmChZaCcfHmDHOB3n27AbL2Hf1 C3+i7quoVpvZ+p5TSGZjLX8nK/gS0NImqTBPF9LYpL5gF49SsiU6rWXFUvqqAi2oSOoPbp1rI2/ TFL/u0DEbu0QYyCMOqU9aL3/Be7hViRJm6UfFZg3oKigrziIAnp24+qwf6V7Yd40OlNFE9naQBH v068DkgXL+bRn+bu4rR4T8Iu80iDLitXlbsNUZ4TZAKKclZv/b3FJ7ivuuz58agAVPGXLOEcp85 yg== X-Gm-Gg: AfdE7clD8sYTtUpFb6yR1FXgojqpTnHHf1AexNqEkLbTMo3mJ6X6/SgvbHaw5+eVaXw 83XRTDZBdIYvI9E3IRquDArVIbA5gBo5JLOiYLlkUIkjSUsNeOAjhTuFLp3R2EOxozPxPQ+tPVQ /y7QKqEinzUzHr8D6q826FuZfkDyqWdjipF14AfhVrT0/4Z6stHR2eKnkfR/Uf4Xjnk47lXHWNp j8xzqDgL25UxGDTT10g6sICEVUH6MtrMMhjbu6P6MU2whVUSZsntyrX86QOUjgvaIv+08054y1O 6+7ihCf81DVC9YwZU8HUkGqinZDldGBllyaYAytpE/Hdq9hvhiHnIDSBvg== X-Received: by 2002:a05:690c:498c:b0:7fd:9dbe:4d87 with SMTP id 00721157ae682-81be2d8a6dcmr19801947b3.52.1783375656735; Mon, 06 Jul 2026 15:07:36 -0700 (PDT) Received: from 298783833264 named unknown by gmailapi.google.com with HTTPREST; Mon, 6 Jul 2026 15:07:35 -0700 Received: from 298783833264 named unknown by gmailapi.google.com with HTTPREST; Mon, 6 Jul 2026 15:07:35 -0700 From: Zsolt Parragi In-Reply-To: References: <45swup77t7utfy33lu47mvkb4exzm3oeakz25abqxuvmsyzt3c@5umrpfgc3ypg> <178066304625.594057.12185296716401427152.pgcf@coridan.postgresql.org> <54uh7vhavffktp72dmjm7ms26lntxacnvpwuaitiez4izugdi6@emwc2yrpqwk2> <178332300475.2568959.4097339122938147476.pgcf@coridan.postgresql.org> MIME-Version: 1.0 Date: Mon, 6 Jul 2026 15:07:35 -0700 X-Gm-Features: AVVi8CdAc42ZPeJdAXlBuhEy1_2byh_EEPTfqpvz5ThT-_tpoR7IJIl6KztbdGE Message-ID: Subject: Re: File locks for data directory lockfile in the context of Linux namespaces To: pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" X-CLOUD-SEC-AV-Sent: true X-CLOUD-SEC-AV-Info: percona,google_mail,monitor X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello! + if (errno == EAGAIN) + ereport(FATAL, + (errcode(ERRCODE_LOCK_FILE_EXISTS), According to fcntl.2, this should handle both EACCESS and EAGAIN: ERRORS EACCES or EAGAIN Operation is prohibited by locks held by other processes. +static int +OFDLockFile(int fd, const char *filename) +... + else + return dup(fd); Isn't this missing an FD_CLOEXEC, so that launched processes doesn't inherit it and keep the lock open possibly longer than needed? Also, shouldn't the code verify the result of dup? (!= -1 / errno) + flock_fd = OFDLockFile(fd, filename); Can't we leak flock_fd in the stale path? + * Close the file descriptor, which keeps the open file description + * lock. + */ + if (lock_file->fd > 0) + close(lock_file->fd); Shouldn't this check for >= 0? + elog(WARNING, "Failed locking file \"%s\", %m", filename); This probably should be: ereport(WARNING, (errcode_for_file_access(), errmsg("could not lock file \"%s\": %m", filename)))