Replace mention of FTP server with more up to date downloads location
While looking at something else, I noticed that we still refer to the "PostgreSQL FTP server" in the MSVC portion of the docs even though the FTP server is long since gone. The attached diff changes it to refer to the downloads section of the web site instead which seems more up to date. -- Daniel Gustafsson https://vmware.com/ ftp_server.diff Description: Binary data
Re: Replace mention of FTP server with more up to date downloads location
On Fri, Jan 22, 2021 at 11:36 AM Daniel Gustafsson wrote: > > While looking at something else, I noticed that we still refer to the > "PostgreSQL FTP server" in the MSVC portion of the docs even though the FTP > server is long since gone. The attached diff changes it to refer to the > downloads section of the web site instead which seems more up to date. Applied, with changing the "on" to "in" per off-list discussion. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Re: Replace mention of FTP server with more up to date downloads location
> On 22 Jan 2021, at 12:51, Magnus Hagander wrote: > > On Fri, Jan 22, 2021 at 11:36 AM Daniel Gustafsson wrote: >> >> While looking at something else, I noticed that we still refer to the >> "PostgreSQL FTP server" in the MSVC portion of the docs even though the FTP >> server is long since gone. The attached diff changes it to refer to the >> downloads section of the web site instead which seems more up to date. > > Applied, with changing the "on" to "in" per off-list discussion. Thanks, that's indeed much better than what I proposed. -- Daniel Gustafsson https://vmware.com/
HeapTupleHeaderData Layout description
Hi, In https://www.postgresql.org/docs/13/storage-page-layout.html we can find on § 68.6.1. Table Row Layout the Table 68.4. HeapTupleHeaderData Layout When additionning Length of differents Fields taht are present we obtain atotal of 4+4+4+4+6+2+2+1 = 27 What doesn't seem to fit with previous indication "There is a fixed-size header (occupying 23 bytes on most machines)" Researching in old doc shows that in 8.2 the documentation https://www.postgresql.org/docs/8.2/storage-page-layout.html indicate 27 bytes (with the same detailled Table) Number 23 appears from Postgres 8.3 In some thread like https://stackoverflow.com/questions/2966524/calculating-and-saving-space-in-postgresql/7431468 It's possible to read that Overhead per tuple (row) ... And at least 24 bytes (23 + padding) for the tuple header ... As there is several thread about this point I suppose there is an evolution between 8.2 and 8.3 with a missdocumentation for an evolution of detailled Table "HeapTupleHeaderData Layout" IS it right ? And in this case what is the real detailled Table ? Thanks for any explanations Regards
Re: HeapTupleHeaderData Layout description
benj@laposte.net writes: > In https://www.postgresql.org/docs/13/storage-page-layout.html > we can find on § 68.6.1. Table Row Layout > the Table 68.4. HeapTupleHeaderData Layout > > When additionning Length of differents Fields taht are present we > obtain atotal of > 4+4+4+4+6+2+2+1 = 27 I think you missed the point that t_cid overlays with t_xvac. regards, tom lane
Re: HeapTupleHeaderData Layout description
Le 22/01/2021 à 17:49, Tom Lane a écrit : > benj@laposte.net writes: >> In https://www.postgresql.org/docs/13/storage-page-layout.html >> we can find on § 68.6.1. Table Row Layout >> the Table 68.4. HeapTupleHeaderData Layout >> >> When additionning Length of differents Fields taht are present we >> obtain atotal of >> 4+4+4+4+6+2+2+1 = 27 > > I think you missed the point that t_cid overlays with t_xvac. > > regards, tom lane > Hi, Thank you for this point. It's more clear. So in fact the error (with number 27) was in the documentation for version before postgres 8.3. In version >=8.3, the overlays precision could be added into sentence "XID for VACUUM operation moving a row version" => "XID for VACUUM operation moving a row version (overlays with t_cid)" or Maybe show t_cid and t_xvac in the same cell into the array could be more clear Example : |===|===|=|| |Field |Type |Length |Description | |===|===|=|| |t_xmin |TransactionId |4 octets |insert XID stamp| |---|---|-|| |t_xmax |TransactionId |4 octets |delete XID stamp| |---|---|-|| |t_cid |CommandId | |insert and/or delete CID stamp | |t_xvac |TransactionId | |XID for VACUUM operation moving | | | | |a row version | | | |4 octets |(t_cid and t_xvax are overlayed)| |---|---|-|| |t_ctid |ItemPointerData|6 octets |current TID of this or newer row| | | | |version | |---|---|-|| |t_infomask2|uint16 |2 octets |number of attributes, plus | | | | |various flag bits | |---|---|-|| |t_infomask |uint16 |2 octets |various flag bits | |---|---|-|| |t_hoff |uint8 |1 octet |offset to user data | |===|===|=|| Thanks, Regards
Re: HeapTupleHeaderData Layout description
benj@laposte.net writes: > Le 22/01/2021 à 17:49, Tom Lane a écrit : >> I think you missed the point that t_cid overlays with t_xvac. > So in fact the error (with number 27) was in the documentation for > version before postgres 8.3. No, the pre-8.3 docs are also correct, for their time. regards, tom lane
Re: Need help on translating documentation
> While I was working on those table changes, I had some occasions > to want to do that sort of thing. I found that it was possible > to do it mechanically using XML tools. Unfortunately I did not > save my scripts, and they were just hacks anyway ;-). But you > might be able to get somewhere with that hint. Thanks for the info. I will try the direction. Actually I expected there are something like auto-generate-from-template systems to create catalogs.sgml. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
