Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i8oDY-00066I-OK for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Sep 2019 16:14:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i8oDX-0003ZB-JR for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Sep 2019 16:14:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i8oDX-0003Yu-7T for pgsql-hackers@lists.postgresql.org; Fri, 13 Sep 2019 16:14:39 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1i8oDV-0002Sw-1Y for pgsql-hackers@lists.postgresql.org; Fri, 13 Sep 2019 16:14:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x8DGEWh3007006; Fri, 13 Sep 2019 12:14:32 -0400 From: Tom Lane To: Amit Khandekar cc: Robert Haas , Tomas Vondra , Alvaro Herrera from 2ndQuadrant , PostgreSQL Hackers Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files In-reply-to: References: <20190911125140.GA21034@alvherre.pgsql> <20190912093055.exeatfemzr3f25yx@development> Comments: In-reply-to Amit Khandekar message dated "Fri, 13 Sep 2019 21:28:12 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7004.1568391272.1@sss.pgh.pa.us> Date: Fri, 13 Sep 2019 12:14:32 -0400 Message-ID: <7005.1568391272@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Khandekar writes: > You mean tracking excess kernel fds right ? Yeah, we can use VFDs so > that excess fds are automatically closed. But Alvaro seems to be > talking in context of tracking of file seek position. VFD does not > have a mechanism to track file offsets if one of the vfd cached file > is closed and reopened. Hm. It used to, but somebody got rid of that on the theory that we could use pread/pwrite instead. I'm inclined to think that that was the right tradeoff, but it'd mean that getting logical decoding to adhere to the VFD API requires extra work to track file position on the caller side. Again, though, the advice that's been given here is that we should fix logical decoding to use the VFD API as it stands, not change that API. I concur with that. regards, tom lane