From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Blank archive_command |
Date: | 2022-01-17 15:35:59 |
Message-ID: | CALj2ACU-iC0peFssoSFa+fsMazpGSh6Q4nf_GVAwWPUV1FUrWA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 17, 2022 at 9:02 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> writes:
> > However, a reasonable thing to do is to
> > emit a WARNING or ERROR-out when archive_command is set to null in
> > it's check_archive_command when archive_mode is on?
>
> We have been burned badly in the past by attempts to do that sort of
> thing (ie, make behavior that's conditional on combinations of GUC
> settings). There tends to be collateral damage along the lines of
> "certain orders of operations stop working". I'm not really eager
> to open that can of worms here.
+1 to create any GUC setting dependencies. Let's leave the
responsibility of setting appropriate archive_command to the archiving
handlers outside postgres. FWIW, having a note in the archive_command
GUC definition in the docs might help to some extent.
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2022-01-17 15:38:43 | Re: 2022-01 Commitfest |
Previous Message | Tom Lane | 2022-01-17 15:32:17 | Re: Blank archive_command |