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 1os9za-0005eS-M0 for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Nov 2022 21:49:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1os9yb-0003DT-Hg for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Nov 2022 21:48:17 +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 1os9yb-0003CW-6c for pgsql-hackers@lists.postgresql.org; Mon, 07 Nov 2022 21:48:17 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1os9yY-0000ah-IN for pgsql-hackers@postgresql.org; Mon, 07 Nov 2022 21:48:16 +0000 Received: by mail-pj1-x102b.google.com with SMTP id r61-20020a17090a43c300b00212f4e9cccdso15997766pjg.5 for ; Mon, 07 Nov 2022 13:48:14 -0800 (PST) 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=gyFY5YSalACAXYEmsJAYu/cE7vIZ+My5XVxNtTO6lfk=; b=YnQ2xu4WeMlkLmzXRn7l9fyJr+WcJOQdGZZaOJ8EMenZ4D/yAksMihfgOZ+oj1DIG6 iPY7MTy+ozNyPX294/V7gyHyz0vmk0BXS3F9YKLRRQek/Xt2RhSnlcxiXZAwWIX44UVk SAt3R68knrsAMIIIbBfPHKkCTsDRCzUKsSqAo5y19VLlZeg6ED0L5OGhy6O/zVpL9E6D lVmHiMWnuDBgcZotyDbB6lPsbBQ/35XLUy4UqqCChLLaolP8LuqgjQXIfgH8/8TTw81T q3HZnOQ7/8L6EFY6p5TXWcY/qD1uaXmqhug2OihlwymBSTGq+8CBSO6vtbgNww/+PojU oncg== 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=gyFY5YSalACAXYEmsJAYu/cE7vIZ+My5XVxNtTO6lfk=; b=ee+7Sg+woqwsEIQ1OXwwXvmbhZdTTlEumiYfjbCFqeuonrPXwQ4Vn/6g7oHKAgu1x7 gCcvR7GXm7msxy8G/StOkyk+nEtfZCL5fpoB+eI8e662JVRS526RYXzp5TZ3Olxjv2Du 89yTRng/F7QCXWfrCjruE8hxTEBdbVwlNvHY7E99opJhfqqUW/5oj/ujxZdEALOhd5VA xaTT1r+YOhuHT1DarYU8wtukrd7LGxf+xVpwxkHSOG5mXDNKrFYXYl+96Hss6wP53V5+ WtY32GeM8+o0g77aavgUwX15mq2W3qBd+ldf0BB5uGEPeMWDS8tgWZQeyMZegvWdhzIt bBPg== X-Gm-Message-State: ANoB5pkwOobspY+PoFtLtR3M2OkPSWJ9t79zD9526qyXI006D6NYcres B0MvU6jgbuSe3MFcEbhCUJA= X-Google-Smtp-Source: AA0mqf4YoH/dYUC07MTiedRbrSevlu54jGDDLCOqNr2780jBPUqA6cBm0byjq/G7ks+//n/sv8yPvA== X-Received: by 2002:a17:902:cf07:b0:188:7e83:c5f1 with SMTP id i7-20020a170902cf0700b001887e83c5f1mr8513488plg.58.1667857691875; Mon, 07 Nov 2022 13:48:11 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id e1-20020a621e01000000b0056bc1a41209sm4961626pfe.33.2022.11.07.13.48.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Nov 2022 13:48:11 -0800 (PST) Date: Mon, 7 Nov 2022 13:48:09 -0800 From: Nathan Bossart To: Bharath Rupireddy Cc: Kyotaro Horiguchi , robertmhaas@gmail.com, pgsql-hackers@postgresql.org Subject: Re: thinko in basic_archive.c Message-ID: <20221107214809.GB632101@nathanxps13> References: <20221020.102647.746666963360821887.horikyota.ntt@gmail.com> <20221021.141346.1491472262189507263.horikyota.ntt@gmail.com> <20221105214651.GC137360@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 Mon, Nov 07, 2022 at 04:53:35PM +0530, Bharath Rupireddy wrote: > The tempfile name can vary in size for the simple reason that a pid > can be of varying digits - for instance, tempfile name is 'foo1234' > (pid being 1234) and it becomes '\'\0\'oo1234' if we just reset the > first char to '\0' and say pid wraparound occurred, now the it becomes > 'bar5674' (pid being 567). The call to snprintf() should take care of adding a terminating null byte in the right place. > BTW, I couldn't find the 80 existing instances, can you please let me > know your search keyword? grep "\[0\] = '\\\0'" src -r > So, IIUC, your point here is what if the copy_file fails to create the > temp file when it already exists. With the name collision being a rare > scenario, given the pid and timestamp variables, I'm not sure if > copy_file can ever fail because the temp file already exists (with > errno EEXIST). However, if we want to be extra-cautious, checking if > temp file exists with file_exists() before calling copy_file() might > help avoid such cases. If we don't want to have extra system call (via > file_exists()) to check the temp file existence, we can think of > sending a flag to copy_file(src, dst, &is_dst_file_created) and use > is_dst_file_created in the shutdown callback. Thoughts? Presently, if copy_file() encounters a pre-existing file, it should ERROR, which will be caught in the sigsetjmp() block in basic_archive_file(). The shutdown callback shouldn't run in this scenario. I think this cleanup logic should run in both the shutdown callback and the sigsetjmp() block, but it should only take action (i.e., deleting the leftover temporary file) if the ERROR or shutdown occurs after creating the file in copy_file() and before renaming the temporary file to its final destination. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com