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 1sUBTK-00170X-Ni for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jul 2024 20:41:58 +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 1sUBTG-0053DP-Vu for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jul 2024 20:41:55 +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 1sUBTG-0053DF-Ld for pgsql-hackers@lists.postgresql.org; Wed, 17 Jul 2024 20:41:55 +0000 Received: from mail-yw1-x1130.google.com ([2607:f8b0:4864:20::1130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sUBTD-0004tE-UZ for pgsql-hackers@lists.postgresql.org; Wed, 17 Jul 2024 20:41:53 +0000 Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-65f880c56b1so374667b3.3 for ; Wed, 17 Jul 2024 13:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1721248911; x=1721853711; darn=lists.postgresql.org; h=user-agent: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=AIBsbYgRrrDo3vDBAM9Mh0I43LaiMb1bXYlIwH4XCv0=; b=frxUpVtLayDIo97qUzmBQ9RAIJZsOPF67OYEMnDcnOL+XsDmX9LkQEqAunIi31LNaq WN7AECLgRF6JqFzw0SDQbck+CzSnb4fZfGKz3ELpt4TCWFpVTIuiWv2RwkoQVqN7DlQJ ljlELropCrFPSUv4QNzz9MF/qrlIwkPx7XiSY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721248911; x=1721853711; h=user-agent: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=AIBsbYgRrrDo3vDBAM9Mh0I43LaiMb1bXYlIwH4XCv0=; b=Pr5CzVJ/5iWotZt6YOXEK59nh5WHr0C5c2v1ZjCvqxmLfcgrSCYJp5efopw2UC980c evE8yAWkcjfcH/fSAU0iaDb7klLPtQuhhqKVsvkU8eeLpGfnn/Su1nalGcgdsenqb+GX dpNivthRR3pZBcGLIJGObya3I67ISIriy3nVidrxKDDRxlQQvPP0doCYNB0oNzadIQsg 6uO46sRKA5o3DPwICbbv/esXpAUOnX/sqq6BJjpMK8xc9Hir8ag2dOWgM8WBIW1KuOSa 3dqc1dXOj+Xf4SlNgTI064sfgILHzkCM2j94uYQNv6dSbYnB1n1PPAJeEDeOP0TZXfsi XOfg== X-Gm-Message-State: AOJu0Yw5rIr/ij5t4lpXyVjHo4gxezr/coowPnVBx3ZcKXTHEjxajc+f hr1xmr4JQwi+Ix8oCMEs5SFNT9kBUHw9dd2XSeeUh8DEMgsmPOS71uVkjxb8hg== X-Google-Smtp-Source: AGHT+IF8FEYq5DvxNY79LG0Rv4hf3Y6yte7Jk3HGNjB6AsGcslgNt2kCa5sbctnipuKRVkAznCN1+A== X-Received: by 2002:a81:93c2:0:b0:65f:c95f:e7c7 with SMTP id 00721157ae682-664fde8047dmr34325687b3.7.1721248910802; Wed, 17 Jul 2024 13:41:50 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::48]) by smtp.gmail.com with ESMTPSA id 00721157ae682-666041c814esm659447b3.135.2024.07.17.13.41.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jul 2024 13:41:50 -0700 (PDT) Date: Wed, 17 Jul 2024 13:41:47 -0700 From: Noah Misch To: Nazir Bilal Yavuz Cc: PostgreSQL Hackers Subject: Re: Use read streams in CREATE DATABASE command when the strategy is wal_log Message-ID: <20240717204147.09@rfd.leadboat.com> References: <20240711235209.f6.nmisch@google.com> <20240716121935.fa.nmisch@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jul 17, 2024 at 12:22:49PM +0300, Nazir Bilal Yavuz wrote: > On Tue, 16 Jul 2024 at 15:19, Noah Misch wrote: > > On Tue, Jul 16, 2024 at 02:11:20PM +0300, Nazir Bilal Yavuz wrote: > > > On Fri, 12 Jul 2024 at 02:52, Noah Misch wrote: > > > > On Tue, Apr 16, 2024 at 02:12:19PM +0300, Nazir Bilal Yavuz wrote: > > > > > --- a/src/backend/storage/aio/read_stream.c > > > > > +++ b/src/backend/storage/aio/read_stream.c > > > > > @@ -549,7 +549,7 @@ read_stream_begin_relation(int flags, > > > > > { > > > > > stream->ios[i].op.rel = rel; > > > > > stream->ios[i].op.smgr = RelationGetSmgr(rel); > > > > > - stream->ios[i].op.smgr_persistence = 0; > > > > > + stream->ios[i].op.smgr_persistence = rel->rd_rel->relpersistence; > > > > > > > > Does the following comment in ReadBuffersOperation need an update? > > > > > > > > /* > > > > * The following members should be set by the caller. If only smgr is > > > > * provided without rel, then smgr_persistence can be set to override the > > > > * default assumption of RELPERSISTENCE_PERMANENT. > > > > */ > > > > > > I believe it does not need to be updated but I renamed > > > 'ReadBuffersOperation.smgr_persistence' as > > > 'ReadBuffersOperation.persistence'. So, this comment is updated as > > > well. I think that rename suits better because persistence does not > > > need to come from smgr, it could come from relation, too. Do you think > > > it is a good idea? If it is, does it need a separate commit? > > > > The rename is good. I think the comment implies "persistence" is unused when > > rel!=NULL. That implication is true before the patch but false after the > > patch. > > What makes it false after the patch? I think the logic did not change. > If there is rel, the value of persistence is obtained from > 'rel->rd_rel->relpersistence'. If there is no rel, then smgr is used > to obtain its value. First, the patch removes the "default assumption of RELPERSISTENCE_PERMANENT". It's now an assertion failure. The second point is about "If only smgr is provided without rel". Before the patch, the extern functions that take a ReadBuffersOperation argument examine smgr_persistence if and only if rel==NULL. That's consistent with the comment. After the patch, StartReadBuffersImpl() calling PinBufferForBlock() uses the field unconditionally. On that note, does WaitReadBuffers() still have a reason to calculate its persistence as follows, or should this patch make it "persistence = operation->persistence"? persistence = operation->rel ? operation->rel->rd_rel->relpersistence : RELPERSISTENCE_PERMANENT; > I think what you said in the counter argument makes sense. Okay.