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 1jLLus-0007ad-6t for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Apr 2020 07:11:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jLLuq-0000Vc-5w for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Apr 2020 07:11:28 +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 1jLLup-0000VN-Qa for pgsql-hackers@lists.postgresql.org; Mon, 06 Apr 2020 07:11:27 +0000 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jLLul-0006jP-M4 for pgsql-hackers@postgresql.org; Mon, 06 Apr 2020 07:11:26 +0000 Received: by mail-wr1-x42c.google.com with SMTP id j17so15984631wru.13 for ; Mon, 06 Apr 2020 00:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:comments:mime-version :content-id:date:message-id; bh=4CWauzuPgP9gx7G12F88d+aStgpvf+b+1jMXQPFvRFc=; b=x5HW3wyQMu23UVLJt13diZBGinFz0+0ssq2y643KcNuBje1SPHytDV4SOosZmanErY BXXCxRQW3yUtEXtBraIrDFKR1MDdEvpMo3GpHBOp1slUWSBvjEkub1R9CPY6vqpziQ8O GBZBOtq3IYGT6k7zmJK6f+aHna/y62UHXBwUP4nBL6qypto6y6boH6sYybyqGIQtuOPm Y/nxlfDr3LH7hwqKoXH5E93A72/IKylmyROdrJ9xy2PTak5P2GfynEUhIHd0OIgLmcQr YGvaj/IoImBL3wduiD0dSPL95gReCwtnDFpAhtj07nYrv/eBbRfB/TuKlW+tByIAz6HK DPIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :comments:mime-version:content-id:date:message-id; bh=4CWauzuPgP9gx7G12F88d+aStgpvf+b+1jMXQPFvRFc=; b=Q2P/hIQIGQZQLjitIAq+c2/GAXYaVWJJukQvElzEl/nX/p3UFLFYGBcqyhX0LGOwgw 9hmm5IGDNcCEq2XHYzPMRqxW3p/kiQDnK5w7T5MlCffTPSAUhpYH2uydp3nuw+RGCQ9h mRchRNRO7R2ml2Hx32pmqQ+l13bB1cR5m/gOTSh178tVw5daq+vM4EgfabLp7xTPAsZq l5G5W4l3JWGKm8FgUdzEjfnBoMbMTmSPE7AveZD1wq4McHUoL+VUTKqX/XrHeYeSChhH prHs/oiJKFNRw+8GCqObAIRpV4KG74oqHVtty8NltmyulaZDrIMvVapjqu9rK8aCl1KR So9Q== X-Gm-Message-State: AGi0Pub3gP7I9/46qcgNvOe06AN7LbNeBy045dVPpZ2cbPskhCukRZgE ctS9yByOfi0OxUC0053lcwFmyQ== X-Google-Smtp-Source: APiQypIkxUPH9eCxtoK6c9d517ocLxuJoDx2Ha4YY1lhcmRtD6vwXBPNPpaaY1krAZP4qWNxp0r1Rw== X-Received: by 2002:a5d:50d1:: with SMTP id f17mr23571644wrt.150.1586157081547; Mon, 06 Apr 2020 00:11:21 -0700 (PDT) Received: from antos ([77.87.240.5]) by smtp.gmail.com with ESMTPSA id a12sm21777114wmj.22.2020.04.06.00.11.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2020 00:11:21 -0700 (PDT) From: Antonin Houska To: Andres Freund cc: Michael Paquier , pgsql-hackers@postgresql.org, Alvaro Herrera Subject: Re: 2pc leaks fds In-reply-to: <20200406054449.ssmrzj4fav3ewvaq@alap3.anarazel.de> References: <20200406025651.fpzdb5yyb7qyhqko@alap3.anarazel.de> <20200406052648.GB2066@paquier.xyz> <20200406054449.ssmrzj4fav3ewvaq@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Sun, 05 Apr 2020 22:44:49 -0700." X-Mailer: MH-E 8.6+git; nmh 1.7; GNU Emacs 26.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26246.1586157152.1@antos> Date: Mon, 06 Apr 2020 09:12:32 +0200 Message-ID: <26247.1586157152@antos> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund wrote: > > From what I can see, the error is that the code only bothers closing > > WALOpenSegment->seg when switching to a new segment, but we need also > > to close it when finishing the business in XLogReaderFree(). > > Yea, I came to the same conclusion and locally fixed it the same way > (except having the close a bit earlier in XLogReaderFree()). It's still not quite clear to me why the problem starts to appear after 0dc8ead46. This patch does not remove any close() call from XLogReaderFree(). > But I'm not sure it's quite the right idea. I'm not sure I fully > understand the design of 0dc8ead46, but it looks to me like it's > intended to allow users of the interface to have different ways of > opening files. If we just close() the fd that'd be a bit more limited. It should have allowed users to have different ways to *locate the segment* file. The WALSegmentOpen callback could actually return file path instead of the file descriptor and let WALRead() perform the opening/closing, but then the WALRead function would need to be aware whether it is executing in backend or in frontend (so it can use the correct function to open/close the file). I was aware of the problem that the correct function should be used to open the file and that's why this comment was added (although "mandatory" would be more suitable than "preferred"): * BasicOpenFile() is the preferred way to open the segment file in backend * code, whereas open(2) should be used in frontend. */ typedef int (*WALSegmentOpen) (XLogSegNo nextSegNo, WALSegmentContext *segcxt, TimeLineID *tli_p); -- Antonin Houska Web: https://www.cybertec-postgresql.com