Re: Duplicate history file?

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: sfrost(at)snowman(dot)net, tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp, masao(dot)fujii(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Duplicate history file?
Date: 2021-06-11 02:48:32
Message-ID: 20210611024832.azj2jbyoj53k2v3z@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 11, 2021 at 11:25:51AM +0900, Kyotaro Horiguchi wrote:
>
> Nevertheless I agree to it, still don't we need a minimum workable
> setup as the first step? Something like below.
>
> ===
> The following is an example of the minimal archive_command.
>
> Example: cp %p /blah/%f
>
> However, it is far from perfect. The following is the discussion about
> what is needed for archive_command to be more reliable.
>
> <the long list of the requirements>
> ====

"far from perfect" is a strong understatement for "appears to work but will
randomly and silently breaks everything without a simple way to detect it".

We should document a minimum workable setup, but cp isn't an example of that,
and I don't think that there will be a simple example unless we provide a
dedicated utility.

It could however be something along those lines:

Example: archive_program %p /path/to/%d

archive_program being a script ensuring that all those requirements are met:
<the long list of the requirements>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-06-11 03:16:40 Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Previous Message Andres Freund 2021-06-11 02:38:16 Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic