On Tue, Nov 16, 2021 at 10:26:11PM -0500, Tom Lane wrote: > I feel like doing an immediate exit() for these errors and not other > ones is a pretty terrible idea, mainly because it doesn't account for > the question of what to do with a failure that prevents us from getting > to the fsync() call in the first place. So I'd like to see a better > design rather than more quick hacking. I confess I don't have a > clear idea of what "a better design" would look like.
[ .. thinks .. ] We cannot really have something equivalent to data_sync_retry in the frontends. But I'd like to think that it would be fine for pg_basebackup to just exit() on this failure so as callers would be able to retry a base backup. pg_receivewal is more tricky though. An exit() would allow for flush retries of a previous WAL segment where things failed, but that stands when using --no-loop (still the code path triggered by this option would not be used). When not using --no-loop, it may be better to actually just retry streaming from the previous point so as the error should be reported from walmethods.c to the upper stack anyway. > However, that's largely orthogonal to any of the things my proposed > patches are trying to fix. If you want to review the patches without > considering the fsync-error-handling problem, that'd be great. I have looked at them upthread, FWIW: https://www.postgresql.org/message-id/yytsj5vlwp5fa...@paquier.xyz Your proposals still look rather sane to me, after a second look. -- Michael
signature.asc
Description: PGP signature
