From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Hannu Krosing <hannuk(at)google(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(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: .ready and .done files considered harmful |
Date: | 2021-05-06 20:01:39 |
Message-ID: | 20210506200139.ztcbtymc2mf7hncn@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-05-06 21:23:36 +0200, Hannu Krosing wrote:
> How are you envisioning the shared-memory signaling should work in the
> original sample case, where the archiver had been failing for half a
> year ?
If we leave history files and gaps in the .ready sequence aside for a
second, we really only need an LSN or segment number describing the
current "archive position". Then we can iterate over the segments
between the "archive position" and the flush position (which we already
know). Even if we needed to keep statting .ready/.done files (to handle
gaps due to archive command mucking around with .ready/done), it'd still
be a lot cheaper than what we do today. It probably would even still be
cheaper if we just statted all potentially relevant timeline history
files all the time to send them first.
> Or should we perhaps have a system table for ready-to-archive WAL
> files to get around limitation sof file system to return just the
> needed files with ORDER BY ... LIMIT as we already know how to make
> lookups in database fast ?
Archiving needs to work on a standby so that doesn't seem like an
option.
Regards,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-05-06 20:08:16 | Re: COPY table_name (single_column) FROM 'unknown.txt' DELIMITER E'\n' |
Previous Message | Andres Freund | 2021-05-06 19:55:20 | Re: Printing backtrace of postgres processes |