Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XGook-0003dh-4N for pgsql-docs@arkaria.postgresql.org; Mon, 11 Aug 2014 12:35:14 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XGooi-0000ro-Ui for pgsql-docs@arkaria.postgresql.org; Mon, 11 Aug 2014 12:35:12 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XGoog-0000qe-SV for pgsql-docs@postgresql.org; Mon, 11 Aug 2014 12:35:11 +0000 Received: from mimolette.dalibo.net ([212.85.154.222]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XGooc-0001on-St for pgsql-docs@postgresql.org; Mon, 11 Aug 2014 12:35:08 +0000 Received: from [192.168.42.48] (unknown [37.162.165.94]) by mimolette.dalibo.net (Postfix) with ESMTPSA id 3E566508013D; Mon, 11 Aug 2014 14:34:52 +0200 (CEST) Message-ID: <53E8B866.20008@dalibo.com> Date: Mon, 11 Aug 2014 14:34:46 +0200 From: Vik Fearing User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: MauMau , PG Docs Subject: Re: pageinspect forks References: <53D8E0D9.9090300@dalibo.com> <510823BF13464AAE872F0C81C194E86C@maumau> <53E7C12F.3020901@dalibo.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090009090103040305000906" X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org This is a multi-part message in MIME format. --------------090009090103040305000906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/11/2014 12:22 AM, MauMau wrote: > From: "Vik Fearing" >> On 08/10/2014 03:24 PM, MauMau wrote: >>> Could you also improve the doc by changing "table" to "relation" in the >>> description of get_raw_page()? Having a quick look at the code, it >>> seems that the function can also handle indexes. >>> >>> table and returns a copy as a bytea value. This >>> allows a >> >> >> Good catch. I wasn't sure whether using "relation" or "table or index" >> was better, but after a quick test it seems it works for sequences, too, >> so I've gone with "relation". >> >> It doesn't work with views, of course, but it does work with >> materialized views. >> >> Modified patch attached. > > Thanks, I marked this as ready for committer. > > I think I'll leave it up to you to decide whether you improve the HINT > message Fujii-san pointed out, which is in src/backend/catalog/catalog.c. I think you're looking at an old version of the code. My understanding of his message was that that patch had already been applied but not backpatched and he wants it backpatched. To wit, that hint message does include "init" on master and it's located in src/common/relpath.c. However, I did find another occurence in the documentation, so third patch attached. -- Vik --------------090009090103040305000906 Content-Type: text/x-diff; name="pageinspect_init_fork.v3.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pageinspect_init_fork.v3.patch" *** a/doc/src/sgml/pageinspect.sgml --- b/doc/src/sgml/pageinspect.sgml *************** *** 28,38 **** get_raw_page reads the specified block of the named ! table and returns a copy as a bytea value. This allows a single time-consistent copy of the block to be obtained. fork should be 'main' for ! the main data fork, or 'fsm' for the free space map, ! or 'vm' for the visibility map. --- 28,39 ---- get_raw_page reads the specified block of the named ! relation and returns a copy as a bytea value. This allows a single time-consistent copy of the block to be obtained. fork should be 'main' for ! the main data fork, 'fsm' for the free space map, ! 'vm' for the visibility map, or 'init' ! for the initialization fork. *** a/doc/src/sgml/storage.sgml --- b/doc/src/sgml/storage.sgml *************** *** 265,272 **** The pg_relation_filepath() function shows the entire path as a substitute for remembering many of the above rules. But keep in mind that this function just gives the name of the first segment of the main fork of the relation — you may need to append a segment number ! and/or _fsm or _vm to find all the files associated ! with the relation. --- 265,272 ---- as a substitute for remembering many of the above rules. But keep in mind that this function just gives the name of the first segment of the main fork of the relation — you may need to append a segment number ! and/or _fsm, _vm, or _init to find all ! the files associated with the relation. --------------090009090103040305000906 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs --------------090009090103040305000906--