Re: Duplicate history file?

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, masao(dot)fujii(at)oss(dot)nttdata(dot)com, michael(at)paquier(dot)xyz, pgsql-hackers(at)lists(dot)postgresql(dot)org, tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp
Subject: Re: Duplicate history file?
Date: 2021-06-16 03:20:55
Message-ID: 20210616032055.gxx2gcmnydkuiw5h@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 15, 2021 at 11:00:57PM -0400, Stephen Frost wrote:
>
> As I suggested previously- this is similar to the hooks that we provide. We
> don’t extensively document them because if you’re writing an extension
> which uses a hook, you’re going to be (or should be..) reading the code too.

I disagree, hooks allows developers to implement some new or additional
behavior which by definition can't be documented. And it's also relying on the
C api which by definition allows you to do anything with the server. There are
also of course some requirements but they're quite obvious (like a planner_hook
should return a valid plan and such).

On the other hand the archive_command is there to do only one clear thing:
safely backup a WAL file. And I don't think that what makes that backup "safe"
is open to discussion. Sure, you can chose to ignore some of it if you think
you can afford to do it, but it doesn't change the fact that it's still a
requirement which should be documented.

> Consider that, really, an archive command should refuse to allow archiving
> of WAL on a timeline which doesn’t have a corresponding history file in the
> archive for that timeline (excluding timeline 1).

Yes, that's a clear requirement that should be documented.

> Also, a backup tool
> should compare the result of pg_start_backup to what’s in the control file,
> using a fresh read, after start backup returns to make sure that the
> storage is sane and not, say, cache’ing pages independently (such as might
> happen with a separate NFS mount..). Oh, and if a replica is involved, a
> check should be done to see if the replica has changed timelines and an
> appropriate message thrown if that happens complaining that the backup was
> aborted due to the promotion of the replica…

I agree, but unless I'm missing something it's unrelated to what an
archive_command should be in charge of?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message houzj.fnst@fujitsu.com 2021-06-16 03:27:24 RE: [bug?] Missed parallel safety checks, and wrong parallel safety
Previous Message Peter Geoghegan 2021-06-16 03:08:00 Re: disfavoring unparameterized nested loops