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 1ksajB-0002Jl-4A for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Dec 2020 00:13:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ksaj9-0002X9-TY for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Dec 2020 00:13:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ksaj9-0002WW-6R for pgsql-hackers@lists.postgresql.org; Fri, 25 Dec 2020 00:13:03 +0000 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ksaj4-0007b2-NX for pgsql-hackers@lists.postgresql.org; Fri, 25 Dec 2020 00:13:01 +0000 Received: by mail-pj1-x102e.google.com with SMTP id v1so1755940pjr.2 for ; Thu, 24 Dec 2020 16:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=G/v2+LSlVd++hOQL+1HoL6x4HCcHxzmO2utooUKMJcA=; b=H4NASyI52ygaRCVQCQzL1JE6oS++ASsVI07BPYLKJ0dhCM0Crrw1wLiUHoh34DCckt 0WMK/dg8BjOByjEIU04M2hT5D/u4kcLdZYvOG2pAk/4g+PRExGWJX1q5SWOgcRguv4mE r989H+kIIwsLi4ubOnq6hMCh/RwaPJW5FHh0/DDHMQ3/zaY7suLdtKq5OTUZRPcQUZYL mMzF6/Hr40cuVDefNuRFyygBgb31NVw5lb1+ZFO4JKJE9TL76ExwiprKxTVFP3ckSFmp mfot6AeZW4+GSUHwuIQ2ywaThfqnNd2/KXbTHaeKXP80JRX1MA0m0hPuLCHGVAibDvMJ QBQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=G/v2+LSlVd++hOQL+1HoL6x4HCcHxzmO2utooUKMJcA=; b=ZdqaeEGOqw5cTDPYlRV94M+SSPkhhPBGGBFxeqn8bxXzF9/KkDg8fsepH+pAEkkO/G UAuKfTbaJGN+qtkIXUUg/+FqpVxVGxdldXvi5tbRravh05CVRXPqziRbcKA22nH2IQhi ZzmKcimWRc3jdmTViJdtYITV3/tRIAZ75M6+P1Ds/4OXAJ4EnCCSoRc94WIt72R7iwAB i0DUubim2KyVxAB0opvvMZCl0BjC6YfvIrpVL+njUpn7x6mUSZ/kkPXYJWn+j6USVlJ7 EiV7sLPgAeGdI/hUzFpxaxd2rfW/kzU4kG1VKahRBM8CMd58joYX0f+1KChkSVBDvG7k a2jQ== X-Gm-Message-State: AOAM530+c+MOb+tPcNE4el3axomMf1x0ZoYwQHbpUAhbClNsYBhLOd9Y QJTKRyel5rkf7TFCs+Z96Pw= X-Google-Smtp-Source: ABdhPJw+7Si3V/+xGJNRU6/mBiy8zG7K1EXebUGwnC1nwHR1TeFKDmTE8Z7S8ESWB83NKqZ81cRR3A== X-Received: by 2002:a17:90a:db48:: with SMTP id u8mr6331452pjx.81.1608855177101; Thu, 24 Dec 2020 16:12:57 -0800 (PST) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id s7sm26726037pfh.207.2020.12.24.16.12.54 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Thu, 24 Dec 2020 16:12:55 -0800 (PST) Date: Fri, 25 Dec 2020 09:12:52 +0900 (JST) Message-Id: <20201225.091252.53717619425847881.horikyota.ntt@gmail.com> To: tsunakawa.takay@fujitsu.com Cc: osumi.takamichi@fujitsu.com, sfrost@snowman.net, masao.fujii@oss.nttdata.com, ashutosh.bapat.oss@gmail.com, pgsql-hackers@lists.postgresql.org Subject: Re: In-placre persistance change of a relation From: Kyotaro Horiguchi In-Reply-To: <20201224.170220.34532914782663309.horikyota.ntt@gmail.com> References: <20201113.172312.1767546251154140847.horikyota.ntt@gmail.com> <20201224.170220.34532914782663309.horikyota.ntt@gmail.com> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Dec_25_09_12_52_2020_873)--" Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ----Next_Part(Fri_Dec_25_09_12_52_2020_873)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello. At Thu, 24 Dec 2020 17:02:20 +0900 (JST), Kyotaro Horiguchi wrote in > The patch is attached to the next message. The reason for separating this message is that I modified this so that it could solve another issue. There's a complain about orphan files after crash. [1] 1: https://www.postgresql.org/message-id/16771-cbef7d97ba93f4b9@postgresql.org That is, the case where a relation file is left alone after a server crash that happened before the end of the transaction that has created a relation. As I read this, I noticed this feature can solve the issue with a small change. This version gets changes in RelationCreateStorage and smgrDoPendingDeletes. Previously inittmp fork is created only along with an init fork. This version creates one always when a relation storage file is created. As the result ResetUnloggedRelationsInDbspaceDir removes all forks if the inttmp fork of a logged relations is found. Now that pendingDeletes can contain multiple entries for the same relation, it has been modified not to close the same smgr multiple times. - It might be better to split 0001 into two peaces. - The function name ResetUnloggedRelationsInDbspaceDir is no longer represents the function correctly. regards. -- Kyotaro Horiguchi NTT Open Source Software Center ----Next_Part(Fri_Dec_25_09_12_52_2020_873)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="v2-0001-In-place-table-persistence-change.patch"