Re: Fix possible 'unexpected data beyond EOF' on replica restart

Поиск
Список
Период
Сортировка
От Anthonin Bonnefoy
Тема Re: Fix possible 'unexpected data beyond EOF' on replica restart
Дата
Msg-id CAO6_XqojxYb=j_rqSi_MH-DB=tZ-OtMQHqEx6xRh9DQrr2uDuQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fix possible 'unexpected data beyond EOF' on replica restart  (Amul Sul <sulamul@gmail.com>)
Список pgsql-hackers
On Wed, Dec 17, 2025 at 8:26 AM Amul Sul <sulamul@gmail.com> wrote:
Thanks for detailed reproducible steps, I can see the reported issue
and proposed patch fixes the same.

Thanks for the review!
 
The deleted code you moved to mdtruncate() should be kept where it
was. We cannot ensure that every extension using this interface will
adhere to that requirement what the comment describes.
 
Yeah, I've overlooked the case of extensions. I've moved back the InvalidBlockNumber assignment.

Furthermore, an extension's routine might miss updating 
smgr_cached_nblocks. To ensure that updates smgr_cached_nblocks 
properly, we should also add an assertion after the call, like this:

        /*
         * Ensure that the local smgr_cached_nblocks value is updated.
         */
        Assert(reln->smgr_cached_nblocks[forknum[i]] != InvalidBlockNumber);

Good point. I've added the assertion. 

I wonder how critical it is to have an up to date value of smgr_cached_nblocks after smgr_truncate. Leaving InvalidBlockNumber was also an option as the next user will ask the kernel for the real size. There are some functions like DropRelationBuffers which rely only on the cached value, so it's probably safer to keep the same behaviour.

Regards,
Anthonin Bonnefoy
Вложения

В списке pgsql-hackers по дате отправления: