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
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 |