Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ojoQY-0007QB-7Z for pgsql-hackers@arkaria.postgresql.org; Sat, 15 Oct 2022 21:10:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ojoQV-0004yP-CF for pgsql-hackers@arkaria.postgresql.org; Sat, 15 Oct 2022 21:10:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ojoQV-0004yG-1A for pgsql-hackers@lists.postgresql.org; Sat, 15 Oct 2022 21:10:35 +0000 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ojoQS-0004mw-AE for pgsql-hackers@postgresql.org; Sat, 15 Oct 2022 21:10:34 +0000 Received: by mail-pg1-x535.google.com with SMTP id 78so7276753pgb.13 for ; Sat, 15 Oct 2022 14:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=s78GeN0Wr5MPf/xc7q3qQiNqVD9ylvpeYXVdRG7cL2U=; b=NG5HpNktvTkBA33kNhKTxH8BvNMcflLBQsoaquy2l6LjRMRcsl4B0tQfkKNMlaw+HW kxiSK/ImwXu9RYdqja4Rk7tFtn1P4LFpN6SMb8Pol8sC2UJ1NNYne7DSHWVx/ukE13GY PrmrWCadX5nnYMm6ZwO7qr2VuK5crXbYJKGvtiaEu5V84i6IP10b5xPp9zNZ9lUg1nDr 0kzsGM1Chu/kl+Ou3ifMBcmmJdxaUg0xSlpkw3gIfNPSfIfFusSNVpfSNOOP2Hwew+BE Ncp29DgIYcxCxex7ZrpVy+X2BAkgxzR11dOAudakrC+OJPx+ibQsfxiZOV4ggnJN5okQ uU9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=s78GeN0Wr5MPf/xc7q3qQiNqVD9ylvpeYXVdRG7cL2U=; b=2J4OlUdRkMJo/i3n3u4Dujll/RhZLqRa54gobSnwrmA1Dc5jpjbxtmH1mlqAhCP9vf gLHe45gL/a91dzqTuE1v8yu/uCzVmtThnbLa4SptZzsrOZ+M9XzawDoBXn7TDA5LTLVc m9m7HQM7Al5UiZAvcmZT8wZkbz6sPT6mnCtC+Z/7yijRUfymhyqHoaHLJAdbhoemHVax P1zdciClrX/A/eAMIdXUoGWa1bes4Aj+CB9CQPat8ZFVBATudzZG8iZtujlEUV8CkaQu SdGDM3bYG/fAX+18KCRTpEOe6/CVoqTQb2FohIPjN+sDnf7hHgDZK6HtnmnbqpswpvWR Houw== X-Gm-Message-State: ACrzQf38CwkHeJh5y6hudd5edFPzBnYnImKnjhr2Mp4646y9qH9WXYGf sTC57uMQ1DTYMwE+zqBaTL4= X-Google-Smtp-Source: AMsMyM5IDvOSPrNxwX8g+bVy2ZH5g7ZFYn7E3EFEsYkmBXLjKzy60IW+SEoZJlYrJPZigQZRY6ef6w== X-Received: by 2002:a63:1521:0:b0:43c:9566:7a6a with SMTP id v33-20020a631521000000b0043c95667a6amr4013513pgl.339.1665868229459; Sat, 15 Oct 2022 14:10:29 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id x22-20020a170902821600b00178b77b7e71sm3742645pln.188.2022.10.15.14.10.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Oct 2022 14:10:28 -0700 (PDT) Date: Sat, 15 Oct 2022 14:10:26 -0700 From: Nathan Bossart To: Bharath Rupireddy Cc: pgsql-hackers@postgresql.org Subject: Re: thinko in basic_archive.c Message-ID: <20221015211026.GA1821022@nathanxps13> References: <20221014044106.GA1673343@nathanxps13> <20221014183310.GB1678424@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Oct 15, 2022 at 10:19:05AM +0530, Bharath Rupireddy wrote: > Can you please help me understand how name collisions can happen with > temp file names including WAL file name, timestamp to millisecond > scale, and PID? Having the timestamp is enough to provide a non-unique > temp file name when PID wraparound occurs, right? Am I missing > something here? Outside of contrived cases involving multiple servers, inaccurate clocks, PID reuse, etc., it seems unlikely. > Hm, we cannot remove the temp file for all sorts of crashes, but > having on_shmem_exit() or before_shmem_exit() or atexit() or any such > callback removing it would help us cover some crash scenarios (that > exit with proc_exit() or exit()) at least. I think the basic_archive > module currently leaves temp files around even when the server is > restarted legitimately while copying to or renaming the temp file, no? I think the right way to do this would be to add handling for leftover files in the sigsetjmp() block and a shutdown callback (which just sets up a before_shmem_exit callback). While this should ensure those files are cleaned up after an ERROR or FATAL, crashes and unlink() failures could still leave files behind. We'd probably also need to avoid cleaning up the temp file if copy_file() fails because it already exists, as we won't know if it's actually ours. Overall, I suspect it'd be more trouble than it's worth. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com