| 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 18:19:56 |
| Message-ID: | 20220707181956.GA2255157@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 07, 2022 at 02:07:26PM -0400, David Steele wrote:
> On 7/7/22 12:18, Nathan Bossart wrote:
>> On Thu, Jul 07, 2022 at 10:46:23AM -0400, David Steele wrote:
>>
>> > 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.
>
> On the PG side, crashes and (IIRC) immediate shutdown.
>
> In general, any failure in the archiver itself. Storage, memory, network,
> etc. There are plenty of ways that the file might make it to storage but
> postgres never gets notified, so it will retry.
>
> Any archiver that is not tolerant of this fact is not going to be very
> useful and this patch only makes it slightly more true.
Ah, got it, makes sense.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-07-07 18:22:51 | Re: remove more archiving overhead |
| Previous Message | David Steele | 2022-07-07 18:07:26 | Re: remove more archiving overhead |