Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rp89y-005De3-Pt for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2024 14:52:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rp89v-00GRjM-Tp for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2024 14:52:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rp89v-00GRht-Hb for pgsql-hackers@lists.postgresql.org; Tue, 26 Mar 2024 14:52:15 +0000 Received: from mail-il1-x130.google.com ([2607:f8b0:4864:20::130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rp89r-006Xz3-Oj; Tue, 26 Mar 2024 14:52:14 +0000 Received: by mail-il1-x130.google.com with SMTP id e9e14a558f8ab-3689a0abfd2so5976135ab.2; Tue, 26 Mar 2024 07:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711464732; x=1712069532; darn=postgresql.org; 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=ygfAg1a2rtCIsQCYbApqitbpeUu71uYsY0Hz9oCt9X4=; b=SqNa0M9lnMFmFDllMhGeEkNAhR/pA2TU85G0Ic4jKM3vqLPR3E0S1dTA0MQsoI7ANt wlaPMl5O1jmg1kKJnrbsnx3YuaeOQpOqL9TAspvH6Tr0+8GKM9Cu8jjTphnjduS/Q4ix c4pBKkt3jmrqr7JvGmWDFDX9dXWtOEngwMIVCgtP8VONy+6fvjZtJHkpYbAMeNo1/Smi p85XRuW0Cvko6qgo+ku5Hda8kayRYQFl3caOxkvuhffMvlyDA8R48n5NxoWSo+yh9bEV uI4e5/+sVb1u2o0jP1kSSX7N14k4ybAvZ7GY/hGFWSsn1CtNAAqsaoMNpFGsudTkKvEg zt5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711464732; x=1712069532; 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=ygfAg1a2rtCIsQCYbApqitbpeUu71uYsY0Hz9oCt9X4=; b=jkwBxQ7/XCI5ZcCIe/jyoKMReYzsaQD0tKK+NGC7uBQGp2pJiWY1QrZ7SYHaj054YY QmYSpstT755PIfWi9N4jX4fS4CUMnj+XAD926NdM4/cJUkXyIFEYnm1zESHUcOyKWOic djtvIW5uMMCt1fm66BTA8CP/qg1OCJiTzFFAO0Vn6huo7KCvZoMGFGugg9mDJ9Ku0XJJ /fRL1uufKXVq+4AFBdvazx/4cy43bhPxtuSufYrwclZzIOLkhH4YX31bziPY4b4ET8WI 7n+39hZPkJApM/UOHzThXnW+OTQ7aFP64JlLi8F9Jg5lrXCU2w4NAD/eSXgAQR5VvnUl 2mDQ== X-Forwarded-Encrypted: i=1; AJvYcCU93Bnb5FTHFNBgEt3+ecJ5ZPk3/Qzepwzd0NnwlZDsWzQAYZGJkeFbtH3OptMajcELq9aMzyUrhiTq1Ao6LZq3LdTep+tHIhKfrhJP X-Gm-Message-State: AOJu0Yy/UV3d/PUeEHKK0QMFm/6D1wo1JwKiit/CPtNAZ46bGdhpfys9 4NWLsaZhjFEaPb1JWu74oiol7k7Oc5ib7IeOGo27cBvoEdPG68Ra X-Google-Smtp-Source: AGHT+IH4wd21m7olLbjXp0hHfdfLSm28vvzxxATSnyAkHa4X+a4LBAALwBuMF3p4neEx/TufQpEHJQ== X-Received: by 2002:a05:6e02:791:b0:368:99a9:3f1c with SMTP id q17-20020a056e02079100b0036899a93f1cmr2730108ils.9.1711464732165; Tue, 26 Mar 2024 07:52:12 -0700 (PDT) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id q4-20020a056e02106400b0036862333c77sm3018703ilj.33.2024.03.26.07.52.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Mar 2024 07:52:11 -0700 (PDT) Date: Tue, 26 Mar 2024 09:52:10 -0500 From: Nathan Bossart To: Robert Haas Cc: Nathan Bossart , "pgsql-hackers@postgresql.org" Subject: Re: pgsql: Allow using syncfs() in frontend utilities. Message-ID: <20240326145210.GA3181099@nathanxps13> References: 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 Fri, Mar 22, 2024 at 12:52:15PM -0400, Robert Haas wrote: > I'd like to complain about this commit's addition of a new appendix. I > do understand the temptation to document caveats like this centrally > instead of in multiple places, but as I've been complaining about over > in the "documentation structure" thread, our top-level documentation > index is too big, and I feel strongly that we need to de-clutter it > rather than cluttering it further. This added a new chapter which is > just 5 sentences long. I understand that this was done because the > same issue applies to a bunch of different utilities and we didn't > want to duplicate this text in all of those places, but I feel like > this approach just doesn't scale. If we did this in every place where > we have this much text that we want to avoid duplicating, we'd soon > have hundreds of appendixes. Sorry I missed this. I explored a couple of options last year but the discussion trailed off [0]. > What I would suggest we do instead is pick one of the places where > this comes up and document it there, perhaps the > recovery_init_sync_method GUC. And then make the documentation for the > other say something like, you know those issues we documented for > recovery_init_sync_method? Well they also apply to this. WFM. I'll put together a patch. [0] https://postgr.es/m/20231009204823.GA659480%40nathanxps13 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com