On Fri, Aug 21, 2020 at 08:07:34PM -0700, David G. Johnston wrote:
> On Fri, Aug 21, 2020 at 5:41 PM Bruce Momjian <br...@momjian.us> wrote:
>
> On Wed, Jul 22, 2020 at 06:58:33AM +0200, Antonin Houska wrote:
> > Tom Lane <t...@sss.pgh.pa.us> wrote:
> >
> > > I don't particularly want to remove the field, but we ought to
> > > change or remove the comment.
> >
> > I'm not concerned about the existence of the field as well. The comment
> just
> > made me worried that I might be missing some fundamental concept. Thanks
> for
> > your opinion.
>
> I have developed the attached patch to address this.
>
>
> I would suggest either dropping the word "potentially" or removing the
> sentence. I'm not a fan of this in-between position on principle even if I
> don't understand the full reality of the implementation.
>
> If leaving the word "potentially" is necessary it would be good to point out
> where the complexity is documented as a part of that - this header file
> probably not the best place to go into detail.
Updated patch.
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
diff --git a/src/include/access/heapam_xlog.h b/src/include/access/heapam_xlog.h
index aa17f7df84..08ab025e67 100644
--- a/src/include/access/heapam_xlog.h
+++ b/src/include/access/heapam_xlog.h
@@ -137,8 +137,7 @@ typedef struct xl_heap_truncate
* or updated tuple in WAL; we can save a few bytes by reconstructing the
* fields that are available elsewhere in the WAL record, or perhaps just
* plain needn't be reconstructed. These are the fields we must store.
- * NOTE: t_hoff could be recomputed, but we may as well store it because
- * it will come for free due to alignment considerations.
+ * FYI, t_hoff could be recomputed each time it is needed.
*/
typedef struct xl_heap_header
{
