Re: archive modules - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: archive modules
Date
Msg-id CALj2ACWAq_gTQ-FhjFvGjhOd5+7qWdepVmYcqsZ_whENshg1zw@mail.gmail.com
Whole thread Raw
In response to Re: archive modules  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: archive modules  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Mon, Oct 10, 2022 at 1:17 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 05.10.22 20:57, Nathan Bossart wrote:
> >> What we are talking about here is, arguably, a misconfiguration, so it
> >> should result in an error.
> >
> > Okay.  What do you think about something like the attached?

The intent here looks reasonable to me. However, why should the user
be able to set both archive_command and archive_library in the first
place only to later fail in LoadArchiveLibrary() per the patch? IMO,
the check_hook() is the right way to disallow any sorts of GUC
misconfigurations, no?

FWIW, I'm attaching a small patch that uses check_hook().

> That looks like the right solution to me.
>
> Let's put that into PG 16, and maybe we can consider backpatching it.

+1 to backpatch to PG 15 where the archive modules feature was introduced.

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Lack of PageSetLSN in heap_xlog_visible
Next
From: Etsuro Fujita
Date:
Subject: Re: Fast COPY FROM based on batch insert