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 1jL3HV-00055B-CT for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2020 11:17:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jL3HU-0004h5-1i for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2020 11:17:36 +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 1jL3HT-0004gy-Jz for pgsql-hackers@lists.postgresql.org; Sun, 05 Apr 2020 11:17:35 +0000 Received: from mail-lf1-x144.google.com ([2a00:1450:4864:20::144]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jL3HN-0007b5-07 for pgsql-hackers@lists.postgresql.org; Sun, 05 Apr 2020 11:17:34 +0000 Received: by mail-lf1-x144.google.com with SMTP id n20so9373064lfl.10 for ; Sun, 05 Apr 2020 04:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=P8rNkjPds8jAZtqYsmcGiK+xmTO/Uqb9e6V9tJUxxno=; b=NObsCPZW0uJ6vatuRlY5MXnj+HemrfpQwBD4BR9iYGJCwhsq0UB6eM8VrCbedroNmK 5DSIDlBABAD1cK8yzJ483MqQ/Epz/ffOgzM88LHLjtuP+8eYSoRfu7ifIX2GGcb2QRag PTNNh3w4CPqnjK3YPrntHh/39c5yscusOh/IAtAmvI2cQcdUc6riSoKjt1UefOFJKjZ3 9l5yZYyETL7YtJhBj6kmZjCqDyjRh6eMUU8xAZ9DdFza9kYK+4UV3Z+PHtpHVh1m6w+b 5vWVrPmihRAUzMj5dHYWYIzEDjxHYWDi2W301Z6Y0tFtWe1oTJogEEgXYSiY/cAmv58i 5yYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=P8rNkjPds8jAZtqYsmcGiK+xmTO/Uqb9e6V9tJUxxno=; b=j3mDBwPdTf1MwT33b+kUdwHwOxyOa6KyVxN1sleWXA9ULgoin/VYJjC/b2f+aBU2Ap u0xNyNL1szcjZ7dFomnn3NXQQkVu4CMR9sGhZ25GDHYnK8fgdHhkDlXuwJGuigCXYopc II5oNcysvPsz4uSHSg/aIKJeRHAZ9ONKu7/XJZRH5DrWDZ77lmbx7ZhQyb4i/juQ3FK7 BBOOx/jJJ2LrLbJ2mOEAit8KqYRVoqj9Xa3oac6R1sZCRyMZlloI8HgqKD6k7FCfgeig AHF65DzOeRHBZJadbK6VS/XTJgwaSRST5bP5QYRkXXngJtextBEZcvtR055RwHtonsAu 4hHQ== X-Gm-Message-State: AGi0PubfwUBYlhkCDpu8MKy4FvXOiARSmqXPys977F+E62EXdqaYQ8Uz uhzI9WCvQnyTwMPS+v3tiE4= X-Google-Smtp-Source: APiQypLzPD0eWAf37DVrtFo+k33rVCBL0nFhZfQCfv+Uj8LVN96XzHTO/+MfCXGd1If6cIhQCiBZ/A== X-Received: by 2002:a19:7015:: with SMTP id h21mr10045220lfc.139.1586085447059; Sun, 05 Apr 2020 04:17:27 -0700 (PDT) Received: from nol (82-64-124-11.subs.proxad.net. [82.64.124.11]) by smtp.gmail.com with ESMTPSA id y25sm2793767lfy.59.2020.04.05.04.17.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Apr 2020 04:17:26 -0700 (PDT) Date: Sun, 5 Apr 2020 13:17:22 +0200 From: Julien Rouhaud To: Masahiko Sawada Cc: Michael Paquier , Robert Haas , PostgreSQL Hackers , Masahiko Sawada Subject: Re: Online checksums verification in the backend Message-ID: <20200405111722.GH1206@nol> References: <20200328121858.GA13605@nol> <20200403093911.GB1206@nol> <20200404090428.GD1206@nol> <20200405084355.GF1206@nol> <20200405094459.GG1206@nol> 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: Precedence: bulk On Sun, Apr 05, 2020 at 08:01:36PM +0900, Masahiko Sawada wrote: > On Sun, 5 Apr 2020 at 18:45, Julien Rouhaud wrote: > > > > On Sun, Apr 05, 2020 at 06:08:06PM +0900, Masahiko Sawada wrote: > > > > > > Why do we need two rows in the doc? For instance, replication slot > > > functions have some optional arguments but there is only one row in > > > the doc. So I think we don't need to change the doc from the previous > > > version patch. > > > > > > > I thought that if we document the function as pg_check_relation(regclass [, > > fork]) users could think that the 2nd argument is optional, so that > > pg_check_relation('something', NULL) could be a valid alias for the 1-argument > > form, which it isn't. After checking, I see that e.g. current_setting has the > > same semantics and is documented the way you suggest, so fixed back to previous > > version. > > > > > And I think these are not necessary as we already defined in > > > include/catalog/pg_proc.dat: > > > > > > +CREATE OR REPLACE FUNCTION pg_check_relation( > > > + IN relation regclass, > > > + OUT relid oid, OUT forknum integer, OUT failed_blocknum bigint, > > > + OUT expected_checksum integer, OUT found_checksum integer) > > > + RETURNS SETOF record STRICT VOLATILE LANGUAGE internal AS 'pg_check_relation' > > > + PARALLEL RESTRICTED; > > > + > > > +CREATE OR REPLACE FUNCTION pg_check_relation( > > > + IN relation regclass, IN fork text, > > > + OUT relid oid, OUT forknum integer, OUT failed_blocknum bigint, > > > + OUT expected_checksum integer, OUT found_checksum integer) > > > + RETURNS SETOF record STRICT VOLATILE LANGUAGE internal > > > + AS 'pg_check_relation_fork' > > > + PARALLEL RESTRICTED; > > > > > > > Oh right this isn't required since there's no default value anymore, fixed. > > > > v9 attached. > > Thank you for updating the patch! The patch looks good to me. > > I've marked this patch as Ready for Committer. I hope this patch will > get committed to PG13. > Thanks a lot!