Re: longfin and tamandua aren't too happy but I'm not sure why

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: longfin and tamandua aren't too happy but I'm not sure why
Date: 2022-09-28 13:48:37
Message-ID: CA+Tgmoa1=UugnXA9TXmN-TEz0VJqACcf+mkcfqnRuqYuPCyCbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 28, 2022 at 9:16 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I agree. I should have gone through and checked that every place where
> RelFileLocator got embedded in some larger struct, there was no
> problem with making it bigger and increasing the alignment
> requirement. I'll go back and do that as soon as the immediate
> problems are fixed. This case would have stood out as something
> needing attention.

On second thought, I'm going to revert the whole thing. There's a
bigger mess here than can be cleaned up on the fly. The
alignment-related mess in ParseCommitRecord is maybe something for
which I could just hack a quick fix, but what I've also just now
realized is that this makes a huge number of WAL records larger by 4
bytes, since most WAL records will contain a block reference. I don't
know whether that's OK or not, but I do know that it hasn't been
thought about, and after commit is not the time to begin experimenting
with such things.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melih Mutlu 2022-09-28 13:49:49 Re: Summary function for pg_buffercache
Previous Message Jonathan S. Katz 2022-09-28 13:42:39 PostgreSQL 15 RC1 release announcement draft