Re: [PATCH] Several refactorings for pg_dump

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Aleksander Alekseev <aleksander(at)tigerdata(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Several refactorings for pg_dump
Date: 2026-08-21 06:28:52
Message-ID: A707EB08-5467-4BD7-8F7A-EFEBC081F963@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 20 Aug 2026, at 14:53, Aleksander Alekseev <aleksander(at)tigerdata(dot)com> wrote:
>
> Hi Daniel,
>
>> I'm not sure that using TAR_BLOCK_SIZE is preferred for
>> a lookahead buffer used to identify the archive format where tar is just one of
>> the options.
>>
>> I would be more inclined to initialize .lookaheadSize like today and then use
>> that instead of the hardcoded 512. Having a buffer in ArchiveHandle without
>> knowing the size of it does seem like a bad practice even if nothing uses it
>> today.
>
> Sounds good. Here is the patch v2.

Seems reasonable. Are there any consumers of the buffer who hardcode an
assumption of its size which could use .lookaheadSize instead? I'll revist
this on Sunday when I get back in the office unless beaten to it.

--
Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2026-08-21 06:43:36 Re: Proposal: Conflict log history table for Logical Replication
Previous Message 达劳里亚斯 2026-08-21 06:19:30 pg_upgrade --copy-file-range fails with EINVAL on Linux 4.19