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