Re: remove more archiving overhead

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remove more archiving overhead
Date: 2022-07-07 16:18:25
Message-ID: 20220707161825.GA2205004@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 07, 2022 at 10:46:23AM -0400, David Steele wrote:
> On 7/7/22 10:37, Robert Haas wrote:
>> On Thu, Jul 7, 2022 at 10:03 AM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>> > Thanks for updating the patch. It looks good to me.
>> > Barring any objection, I'm thinking to commit it.
>>
>> I don't object, but I just started to wonder whether the need to
>> handle re-archiving of the same file cleanly is as well-documented as
>> it ought to be.
>
> +1, but I don't think that needs to stand in the way of this patch, which
> looks sensible to me as-is. I think that's what you meant, but just wanted
> to be sure.

Yeah, this seems like something that should be documented. I can pick this
up. I believe this is an existing problem, but this patch could make it
more likely.

> There are plenty of ways that already-archived WAL might get archived again
> and this is just one of them.

What are some of the others? I was aware of the case that was fixed in
ff9f111, where we might try to re-archive a file with different contents,
but I'm curious what other ways you've seen this happen.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message a.kozhemyakin 2022-07-07 16:38:51 Re: SQL/JSON: functions
Previous Message Bruce Momjian 2022-07-07 16:17:40 System catalog documentation chapter