Message-ID: <be50d6d6-ebb7-697d-282a-6cfdda5efc05@gmail.com>
Date: Thu, 15 Dec 2022 11:20:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.5.1
Subject: Re: Minimal logical decoding on standbys
Content-Language: en-US
To: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
 Ibrar Ahmed <ibrar.ahmad@gmail.com>, Amit Khandekar
 <amitdkhan.pg@gmail.com>, fabriziomello@gmail.com,
 tushar <tushar.ahuja@enterprisedb.com>,
 Rahila Syed <rahila.syed@2ndquadrant.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <4b19419f-2e7c-a76b-c948-26d10af6693d@gmail.com>
 <20221207175824.apmc5clnj2fdjkaq@awork3.anarazel.de>
 <fe81c2e4-aeca-4e57-b453-f183531ce389@gmail.com>
 <09c26df0-c5f9-eae0-5a6a-10fb00b0522e@gmail.com>
 <CA+TgmoY0df9X+5ENg8P0BGj0odhM45sdQ7kB4JMo4NKaoFy-Vg@mail.gmail.com>
 <9f0a021e-40e1-0ae6-8086-a4457c99749e@gmail.com>
 <CA+Tgmoa1cZSo1tUTzxS+RyniMuNtkpxUeEhnD2+-mvJodVtdSQ@mail.gmail.com>
 <0ae83e69-bda0-0eb8-ef4a-d169292e3f66@gmail.com>
 <47f5faf0-6a6d-602a-5d5b-9449ca74c6ad@gmail.com>
 <CA+TgmoaVcu_mbxbH=EccvKG6u8+MdQf9zx98uAL9zsStFwrYsQ@mail.gmail.com>
 <20221214173552.sshklqvwezeo52h3@alap3.anarazel.de>
 <CA+TgmoZ8-DXtDMMDGggFkSYyO8nmNdBKWjV6Ts-zYGR9p5sK5g@mail.gmail.com>
From: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>
In-Reply-To: 
 <CA+TgmoZ8-DXtDMMDGggFkSYyO8nmNdBKWjV6Ts-zYGR9p5sK5g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/be50d6d6-ebb7-697d-282a-6cfdda5efc05%40gmail.com>
Precedence: bulk

Hi,

On 12/14/22 6:48 PM, Robert Haas wrote:
> On Wed, Dec 14, 2022 at 12:35 PM Andres Freund <andres@anarazel.de> wrote:
>>>   typedef struct xl_heap_prune
>>>
>>> I think this is unsafe on alignment-picky machines. I think it will
>>> cause the offset numbers to be aligned at an odd address.
>>> heap_xlog_prune() doesn't copy the data into aligned memory, so I
>>> think this will result in a misaligned pointer being passed down to
>>> heap_page_prune_execute.
>>
>> I think the offset numbers are stored separately from the record, even
>> though it doesn't quite look like that in the above due to the way the
>> 'OFFSET NUMBERS' is embedded in the struct. As they're stored with the
>> block reference 0, the added boolean shouldn't make a difference
>> alignment wise?
>>
>> Or am I misunderstanding your point?
> 
> Oh, you're right. So this is another case similar to
> xl_btree_reuse_page. In heap_xlog_prune(), we access the offset number
> data like this:
> 
>                  redirected = (OffsetNumber *)
> XLogRecGetBlockData(record, 0, &datalen);
>                  end = (OffsetNumber *) ((char *) redirected + datalen);
>                  nowdead = redirected + (nredirected * 2);
>                  nowunused = nowdead + ndead;
>                  nunused = (end - nowunused);
>                  heap_page_prune_execute(buffer,
> 
> redirected, nredirected,
>                                                                  nowdead, ndead,
> 
> nowunused, nunused);
> 
> This is only safe if the return value of XLogRecGetBlockData is
> guaranteed to be properly aligned,

Why, could you please elaborate?

It looks to me that here we are "just" accessing the
members of the xl_heap_prune struct to get the numbers.

Then, the actual data will be read later in heap_page_prune_execute() from the buffer/page based on the numbers we got from xl_heap_prune.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com