From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Nikolay Shaplov <n(dot)shaplov(at)postgrespro(dot)ru> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pageinspect patch, for showing tuple data |
Date: | 2015-09-26 11:57:25 |
Message-ID: | CAB7nPqTF+05xQCX-rzZ3epaWX0vtnky5aXQrduvXFTm8i9bQ5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Sep 26, 2015 at 1:46 AM, Nikolay Shaplov wrote:
> В письме от 25 сентября 2015 20:59:29 пользователь Michael Paquier написал:
>> Thanks! I just had a short look at it:
>> - I am not convinced that it is worth declaring 3 versions of
>> tuple_data_split.
> How which of them should we leave?
The one with the most arguments. Now perhaps we could have as well two
of them: one which has the minimum number of arguments with default
values, and the second one with the maximum number of arguments.
>> - The patch does not respect the project code style,
>> particularly one-line "if condition {foo;}" are not adapted, code line is
> limited
>> to 80 characters, etc. The list is basically here:
>> http://www.postgresql.org/docs/current/static/source.html
> I did my best. Results are attached.
Thanks, it looks better.
>> - Be aware of typos: s/whitch/which is one.
> I've run spellchecker on all comments. Hope that I removed most of the
> mistakes. But as I am not native speaker, I will not be able to eliminate them
> all. I will need help here.
I have not spotted new mistakes regarding that.
>> + <entry><structfield>t_infomask2</structfield></entry>
>> + <entry><type>integer</type></entry>
>> + <entry>stores number of attributes (11 bits of the word). The
>> rest are used for flag bits:
>> +<screen>
>> +0x2000 - tuple was updated and key cols modified, or tuple deleted
>> +0x4000 - tuple was HOT-updated
>> +0x8000 - this is heap-only tuple
>> +0xE000 - visibility-related bits (so called "hint bits")
>> +</screen>
>> This large chunk of documentation is a duplicate of storage.sgml. If
>> that's really necessary, it looks adapted to me to have more detailed
>> comments at code level directly in heapfuncs.c.
> Hm... There is no explanation of t_infomask/t_infomask2 bits in storage.sgml.
>
> If there is no source of information other then source code, then the
> documentation is not good.
pageinspect is already something that works at low-level. My guess is
that users of this module are going to have a look at the code either
way to understand how tuple data is manipulated within a page.
> So I would consider two options: Either move t_infomask/t_infomask2 details
> into storage.sgml or leave as it is.
The documentation redirects the reader to look at htup_details.h (the
documentation is actually incorrect, I sent a separate patch), and I
see no point in duplicating such low-level descriptions, that would be
double maintenance for the same result.
> I am lazy, and does not feel confidence about touching main documentation, so I
> would prefer to leave as it is.
Your patch is proving the contrary :) Honestly I would just rip out
the part you have added to describe all the fields related to
HeapTupleHeaderData, and have only a simple self-contained example to
show how to use the new function tuple_data_split.
>> The example of tuple_data_split in the docs would be more interesting
>> if embedded with a call to heap_page_items.
>
> This example would be almost not readable. May be I should add one more praise
> explaining where did we take arguments for tuple_data_split
I would as well just remove heap_page_item_attrs, an example in the
docs would be just enough IMO (note that I never mind being outvoted).
Btw, shouldn't the ereport messages in tuple_data_split use
error_level instead of ERROR?
Regards,
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2015-09-26 12:30:27 | Re: Partitioned checkpointing |
Previous Message | Amit Kapila | 2015-09-26 11:47:32 | Re: WIP: Rework access method interface |