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 1jsTIQ-0003HX-3x for pgsql-novice@arkaria.postgresql.org; Mon, 06 Jul 2020 15:44:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jsTIP-000141-0I for pgsql-novice@arkaria.postgresql.org; Mon, 06 Jul 2020 15:44:41 +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 1jsTIO-00013c-QN for pgsql-novice@lists.postgresql.org; Mon, 06 Jul 2020 15:44:40 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jsTIM-0007ds-L2 for pgsql-novice@lists.postgresql.org; Mon, 06 Jul 2020 15:44:39 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 066FiZv31377222; Mon, 6 Jul 2020 11:44:35 -0400 From: Tom Lane To: Jialun Zhang cc: Gerald Cheves , Laurenz Albe , pgsql-novice@lists.postgresql.org Subject: Re: What's the best practice to compare the transaction with the checkpoint? In-reply-to: References: <0bf46f63bd9f7e57a83710644a0ed4cf5f6c52f0.camel@cybertec.at> <0e86755d-57aa-9c31-31d2-f90b61456c96@verizon.net> Comments: In-reply-to Jialun Zhang message dated "Mon, 06 Jul 2020 11:27:39 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1377220.1594050275.1@sss.pgh.pa.us> Date: Mon, 06 Jul 2020 11:44:35 -0400 Message-ID: <1377221.1594050275@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Jialun Zhang writes: > Actually I am trying to add file support for TOAST. I mean store the > toasted value in the file system and leave a file path in the toast > pointer. Why in the world would that be a good idea? > Therefore, for garbage collection, we need to remove the file > after confirming that a deleted tuple is older than the latest checkpoint. Even granting that shoving each toasted value into its own file is a sane design, I do not see why you'd need to invent a GC mechanism for it. Seems like you could drive removal of the file off vacuum's removal of the parent tuple. Moreover, even if you want to do it like that, you still don't need to know whether the deleting transaction is older than the last checkpoint; indeed that's entirely the wrong question. What you need to know is whether it's older than global xmin, so that it's certain no other transaction will wish to fetch the field value. regards, tom lane