Re: [PG19]pg_verifybackup never finishes on a gzip-compressed tar backup

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: shihao zhong <zhong950419(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, sulamul(at)gmail(dot)com
Subject: Re: [PG19]pg_verifybackup never finishes on a gzip-compressed tar backup
Date: 2026-10-08 17:28:45
Message-ID: cdfefab5-d04a-4003-bf0d-ff9fa45515f4@dunslane.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2026-10-08 Th 10:14 AM, Andrew Dunstan wrote:
>
> On 2026-10-07 We 8:48 PM, Chao Li wrote:
>>
>>> On Oct 7, 2026, at 19:44, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>>>
>>>> On 6 Oct 2026, at 03:48, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>>>> I took a look at the code and I think we are solving different
>>>> problems.
>>> I concur that this is a separate issue.  Today I returned to looking
>>> at the
>>> truncation patchset and I am including this fix in that review effort.
>>>
>>> --
>>> Daniel Gustafsson
>>>
>> Sorry for the confusion. I was on vacation and didn’t look into the
>> patch closely.
>>
>> This seems to be an old bug that couldn’t be triggered before PG19
>> (b15c1513984 added tar support to pg_waldump). So, I agree with
>> Melanie that this should be an 19 open item.
>>
>> The patch calls inflateReset() after each member finishes, allowing
>> decompression to continue with the next member, which looks like a
>> correct fix to me.
>>
>
> Yes, looks good to me. I will commit later today.
>
>

On re-reading I see Daniel is going to address it.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Bharath Rupireddy 2026-10-08 17:27:29 Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers