| From: | David Steele <david(at)pgmasters(dot)net> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| 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:07:26 |
| Message-ID: | 58b2ae42-5378-778f-e198-3dcaf5ecc47a@pgmasters.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Regards,
-David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-07-07 18:19:56 | Re: remove more archiving overhead |
| Previous Message | Tom Lane | 2022-07-07 18:02:24 | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower |